When I took programming classes, one professor offered this piece of advice: whatever you do, don’t work on a payroll application. Why not? Because if you screw up your company’s payroll, everyone you work with is going to hate you.
I think that advice probably had some solid life experience behind it. If you’ve been a developer for a few years, chances are you’ve been responsible for keeping several different applications running. For those of us who measure our tenure in decades, it’s likely we’ve worked on dozens of applications – and also that at least one of those was really awful.
An incorrect production deployment caused Knight Capital Group to lose close to $500 million in one day. A bug in the initialization code for the Therac-25 radiation machine resulted in multiple deaths from radiation poisoning. Some applications are unappealing because they can leave you, or your organization, exposed.
As one of our solutions architects put it “working on any healthcare applications or ones that can seriously and directly impact someone’s finances would be my worst case scenario.” I would add to this list transportation systems (flight/train/rockets and soon, autonomous vehicles) and possibly, applications for use in the legal profession, or by any other organization likely to sue.
Developers who work in these fields have a good understanding of what could actually cause serious damage, and usually have safeguards in place to prevent that ever happening. Some of those safeguards may have actually been put in place after the fact – for example, when a payment system issued checks for ten times the correct amount due to a decimal point error. Software errors are a fact of life and kudos to the developers who shoulder these kind of responsibilities every day.
Another major factor is an application’s tech stack. Legacy applications, for obvious reasons, rate the worst. Many were designed based on earlier paradigms that allowed combining presentation, business logic and database access into one module. Even if the initial developers designed the architecture with some forethought, it’s unlikely subsequent developers respected their standards. On Quora, Bob Juch wrote:
“One that was written 30 years ago and has been changed by many different people over the years. You generally wind up with spaghetti code that is impossible to understand without spending days deciphering it.”
In cases like this, making changes to code becomes a digital version of Jenga – you never quite know what is going to happen, even with seemingly minor changes.
Another worst case scenario is to be saddled with an application built on technology that is no longer supported. Although internet forums make it easier now, there may no longer be anyone available to help you when you encounter an error. Second to this is migrating an application to a new platform. It will likely be an enormous effort that is undervalued by the organization.
And, of course, even the best application, if it has been developed using an older technology, adds little to your resume, except as it improves your understanding of the business logic.
Which leads to the next factor: the application type.
One of the more interesting things about development is the insight into business processes that you get from working on different applications. Developers tend to be gifted at finding something interesting in the most arcane details of an application.
But some applications are simply more interesting than others, or may just fit better with an individual’s personality. While nobody wants to work on a system that crashes constantly, there are developers who are at their best when firefighting – quick on their feet, fearless and creative. They may prefer having to focus on one big problem or just the excitement that comes from solving a problem under pressure. This type of developer is probably not going to be satisfied supporting an application that features lots of long running jobs, is highly stable and needs only occasional enhancements.
Another factor that can be important is the application’s business cycle. It’s no fun to spend years working on applications that have long development cycles, or those with an end of year crunch time.
End users, too, can make working on an application hellish. Dev’s tend to have antipathy towards their end users, and sometimes it’s for good reasons. Users may not have an understanding of the level of effort involved in maintaining and enhancing their application. They may be defensive, assuming that they’ll be blamed for errors that occur. Or they may be unreliable subject matter experts, or require you to go through management for everything.
Management is, of course, usually the real problem here. On Quora, John McLeod put together an excellent list of problems that (almost all) originate with management:
- Aggressive deadlines.
- Feature creep.
- Long debug cycles.
- Bad build infrastructure.
- Failure of the managers to listen to the engineers.
- Task churn. The inability to ever get anything completed because something more urgent is pushed in to the task list.
- Toxic work culture of some sort.
- A large engineering debt.
So what’s the worst application?
If you score your application based on these factors, you may be surprised where you land. For example, I worked on tax systems for several years. No one gets excited at the thought of working on a tax application. However, tax systems have some advantages. There are clear requirements from the IRS, who send out new regulations every year. Deadlines are set in stone. No matter how crazy things get, there’s a guaranteed hard stop. In addition to all of this, taxes have a set expiration date of seven years. That makes it easy to keep on top of versions and backups, and gives your organization a clear path to move off of outdated technology.
There is good reason to believe that the worst application you have ever worked on is the last one. Because most likely you still remember all the things that went wrong: the serious production problems, minor glitches and shortcomings that ultimately led you to move elsewhere. (It’s also likely that you are right now being blamed for all the above, it’s the last developer who touched it rule in action.) Unless you’ve worked on your current application for several years, you may not yet have fallen out of love with it. But, given enough time – and enough bugs – you may get there yet.