The plight of the software developer

The application. Whether we are swiping through colorful icons on our smartphone home screens or logging on to our laptop's operating system, the app is everywhere. In fact, the term is used so frequently that it's difficult to give app a proper definition.

So, rather than attempt to define what apps are, we can surely define what they do: solve problems. Apps can provide solutions to some of our most critical business headaches, saving and making money for organizations (and individuals). But more importantly, they often present users with unrealized needs. Think about how many people consider Twitter, Facebook, and LinkedIn on their smartphone to be a necessity to their daily lives.

We typically call the minds behind applications software developers. But life for the software developer wasn't so easy 20 years ago. A developer would hack away on their home or office desktop, perfecting and testing their code into the late hours of the night. When the time for them to share their work with the world, they would need a physical computing device with CPU, disk, and memory. The computer would likely require internet access so it could reach a greater population. And in order to make that happen, a software developer would typically rely on a group of system engineers to call up a hardware vendor and get this machine shipped to the office or data center.

After going through the grueling process of getting the machine unboxed, racked, stacked, and wired up, system engineers would then need to configure the operating system, install the necessary programs and frameworks, and ensure the software developer could connect to the machine from their desktop. Consider some of the technical practices at this time: high availability and fault tolerance, although widely discussed, were not commonly enforced.

Once the servers were ready to go, the software developer would share their masterpiece, placing it on the provided infrastructure. As users accessed the application, all would be great... until the app was no longer accessible. Suddenly, the software developer's phone would ring in the middle of the night. System engineers would struggle to fix hardware failures, thus bringing down the application and facing many angry end users. This required trips to the data center—which itself needed disaster recovery plans in case of a fire, flood, or storm. And how about if the application had a spike of major success? If tons of users rushed to type the URL into their browsers and navigate to the site, resources on existing hardware could be overloaded. The system engineers would need to purchase and install additional servers, firewalls, and load balancers to provide more resources for the additional traffic. All of these potential hazards could be a headache for everyone involved—especially a software developer whose focus should stay on the application itself.