We Know Job One, What is Job Two?

Wednesday, October 3, 2007 • edited Friday, February 7, 2020

As a software developer the first thing you need to think about when writing new software is, “Why am I writing this code?” If, after popping the why stack, you don’t answer, “because it solves a customer story” then you are doing something wrong. I talk about this a bit in an old topic, “1, 0, 0 in x seconds”, and Coding Horror had a post entitled “Can your team pass the elevator test?” last week that talks about something similar.

Today, I want to focus on what is job two. For me Job two is a simple three letter acronym; S.U.M. Sure you can write code in no time that will pass the “Why am I writing this code” test, and I bet you could hire a high school kid to do it in no time flat for very little money. The next step is hard though.

S.U.M. stands for Security, Upgradability, and Maintainability. I know the second word isn’t really a word, but it fits my acronym. Most college classes now do a good job of teaching security, and anyone that’s been developing for more than a year has thought about it. Second to getting the application to do what it is supposed to do, security is the most important task a developer needs to think about.

After Security comes upgrade-ability, or the resiliency of your application to not break when you make changes to it. If you practice a good agile method of constantly refactoring your code. This helps make changes effect as few moving parts as possible. As you are coding, an experienced programmer will find common patterns and pre-factor those to save time later.

This leads into the final step, Maintainability. Someone is going to have to maintain your software, and although part of maintenance is adding new functionality, another part is tracking down those remaining bugs that can be nasty. If your code is laid out well, you use common coding standards, and you’ve documented your code the task of tracking down bugs or bringing another engineer up to speed on your code can be less difficult.

The problem with “Job Two” is that nobody wants to pay for it. A customer will comment on the fact that if job one is getting the software to work to their specs then there really isn’t a job two because the software is done. In my professional career I’ve found that companies that are licensing their software and charging for yearly maintenance will usually care more about job two than companies that charge for time and materials. In fact I’ve found the most frustrating aspect of being independent is to sell my clients on job two. This becomes especially true when they have it in their mind that job one is all they need and they can hire a high school student to do it.

Maybe I’m not seeing something here, but how do you sell Job Two to your clients?

Edit: I had a link to a blog post titled “Popping the Why Stack” that exemplified the Why am I doing this? Question nicely. However, I now see that link is dead. The link to Coding Horror’s blog from last week is still good though.

Software Development

Localizable Silverlight

The Little BR that Should Not