Setting Up Development

While it is not always true, you’ll frequently find that in restaurants there is a reasonable correlation between the quality of the food and the management of the kitchen. In my youth I had always found that a messy kitchen often meant low quality food and/or bad service. Of course it’s not always that simple, but usually a disaster area behind the curtains percolated out to the rest of the organization. Since I prefer to ‘do things well if I have to do them’ when searching for jobs back then, I stayed far away from disorganized, sloppy or dirty restaurants, even if it was well-hidden behind the scene.

The same is essentially true in software development. Projects that are set up correctly have strong processes, gravitate towards best practices and control the client’s expectations are considerably more likely to produce quality software. The correlation isn’t always as strong though, since I have seen smooth development shops that still produce fugly software. But I’ve never seen a badly organized shop produce excellence.  

One far too common problem I’ve seen is that the client expectations are out of whack. In the printing industry people often say “Fast, Cheap or Quality, pick two” as the means to explain the types of trade-offs necessary when purchasing print work. In software we get the same saying but it ends with “pick one”. I figure it’s worse for our industry because our work is considerably longer. Print jobs are often measured in hours, days or perhaps weeks, while software is usually measured in weeks, months and years. I’ve seen far too many software projects where clients insist on all three and then have a hard time understanding why some “fiddling” with a few screens might require more than a trivial effort.

A development project that is set up well not only attends to the implementation and distribution of software, but it also must control the client’s expectations. They need to be reasonable. Failure to do this means too much pressure on features and quick fixes, which means accumulating a heavy technical debt. Left unchecked, the project spirals downwards until it combusts.

You can see the symptoms of that type of pressure directly in the code base. Poor analysis, little design, poor use of tools and overly frequent ‘micro’ releases. As well, there is generally a high bug count and a lot of time burned on ‘second-line support’. If developers are busy with band-aides then clearly they’re not coding new stuff. Too much support and too little features just amplifies the pressure, which eventually becomes so toxic that big things start to break.

Getting out of this type of spiral can be difficult or impossible. Resetting the expectations of people who are already disappointed is an extremely tough task. However, just like those reality TV shows where they help people in serious financial debt learn about handling their finances (like Til Debt Do U$ Part) in a more reasonable manner, the ticket to really fixing the development problems is to tackle the technical debt, which mostly means being cost conscious (features & make-work) and reducing lifestyle expectations (release dates). Digging out takes a massive amount of time and means a lot less progress, but it only gets worse if it is put off for longer.

Reversing the slide means revisiting the development and release procedures. It also means lots of cleanup and refactoring. And it usually means revisiting all of the development tools to upgrade their usage to known best practices. For confidence, a few low hanging features might be tossed in as well, but all major changes need to be put on hold until the implementation and release process stabilizes. A smooth development effort should produce minimal support effort. It should be reliable and repeatable. The code should be clean and consistent.

Getting back to the kitchen in a messed up restaurant, not only do you need to clean up the work area and replace any defective equipment, but you also need to set some processes in place to insure that it doesn’t happen again. Once that back-room problem has been dealt with, you can consider a new strategy and/or a new menu, but neither of those will help if the kitchen lacks the ability to execute.

You’d think that new projects were less vulnerable to this type of problem, but most often the pressure to get something working right away overrides the desire to set things up properly. The developers start letting little issues slip and then after enough time, they get hit with ‘death by a thousand cuts’. The most visible “source” of the problem is the client expectations, but they only become overwhelming because of a lack of management. Still it is ultimately up to the developers to ‘insist’ that the technical debt not be ignored. At some point it will always be dangerously large, so at very least ‘cleanup’ should be a recurring work item. Personally I like to start each new development iteration with some significant cleanup, mostly because its boring and it gives one a chance to take a breather after the last release. If that becomes a steady habit, while there is always technical debt and time pressure, at least it never builds up to toxic levels.

In the end its not just what you code, but how you code it and how you leverage the development and systems tools as well. Digging out of technical debt is an on-going problem and mostly the fixed time allocated to do the work should be relative to the size of the debt. It doesn’t need to happen in one big effort, but it can’t be ignored indefinitely either. A smooth development process means that the developers can spend more time contemplating the behavior of the code, which is really the only route to quality. A disorganized process means a strong head wind which is only overcome by dangerous short-cuts. Thus smooth is good and it is a primary requirement to achieving quality. You can’t have the later without spending time to get the former.