February, 19 2004

I’ve developed a theory of commercial software development, that has made me more accepting of imperfection, less-stressed and happier with my job. I say:

If you try to do your software development exactly right, the project will fail. If you don’t try to do anything right, the project will fail. If you pick just few areas and do them well, the project has a chance.

Trying to do everything exactly right will eventually fail because doing everything exactly right —total planning, precise requirements, detailed designs, thorough reviews, three types of testing—is a huge effort. For all but the most complex of projects, a lot of that effort is wasted. Wasted effort means whoever is paying for the software is paying too much money for what they get. <yoda-voice>Wasted-money leads to tension. Tension leads to disrespect. Disrespect leads to distrust. Distrust leads to failure. Failure leads to suffering.</yoda-voice>¹

At the other extreme, not doing anything right is a shortcut to failure. People don’t study software engineering for years and years because it is simple. If a team goes at a software project without planning, requirements, design or testing, they will probably produce a lot of code, but not code that does what the person who is paying for the software wants it to do.

The successful projects I have worked on have taken a middle road. They take limited resources and a non-trivial problem and work out how best to apply one to the other. My theory is that, if you do just a few things really well, it alleviates the pressure in a whole range of areas.

Here are some practices I’ve used, and their effect on the project.²

1. Code Reviews. Ensure that at least two sets of eyes cross every piece of code. The review weeds out the most egregious errors and hacks and increases the team’s common understanding of the code. The fact of the review provides a concrete milestone, which helps with planning and tracking.
2. Perfect Javadoc For the project’s most complex and important classes, ensure that the documentation is always complete, accurate and helpful. The act of documenting causes the developer to think about both the API they are providing and the internal workings of their classes. It also makes other developer’s lives easier when they come to use or debug these classes and looks impressive when you show the client.
3. Unit Tests Pick one or more layers in your system. Ensure that every class in those layers is thoroughly tested. Increases confidence that the tested classes are working, knowledge of classes under test and general team knowledge of the system.
4. Thorough Requirements Document the appearance and behaviour of each part of each window, page or screen, as well as non-functional requirements. Makes the developer’s and tester’s jobs simpler. Defines scope of system, sets early expectations and assists planning and tracking tasks.
5. Stand-up Meeting Communicate status once a day in a short but formal meeting. Assists with planning and tracking. Increases developer knowledge. Finds problems early.

Each practice affects many areas of the project; picking a good range of mostly non-overlapping practices markedly improves a project’s chance of success.

While there is no magic recipe, exactly which practices the team chooses to do doesn’t matter as much as that they do choose some and then do them.

I don’t stress when the project isn’t doing everything right, or even when it isn’t doing all the things that I think it should be doing, so long as some things are being done right and nobody is trying to do everything right. I have a much better tolerance for software development process “imperfections” than I did a few years ago. In fact, I always welcome a few.

¹It’s rare for a team of more than two people to agree on what ‘exactly right’ means anyway. Disagreement leads to tension. Tension leads to…

²I’m not recommending any or all of these for your project. You decide what’s right for your project, and why.