What Does Software Need?

You may (or may not) be familiar with Maslow’s Hierarchy of Needs. This is a theory of developmental psychology that is usually demonstrated with a pyramid. The most essential human needs, e.g. food, water, air, are on the first level, while subsequent, more sophisticated needs (recognition, friendship and so on) are higher up. The theory states that in order to move towards the top-most level (Self Actualisation) the lower, more basic needs must be met. You can’t satisfy the need for justice if you don’t have sleep!

A similar hierarchy exists in software development. The layers are (from bottom to top): Source Control, Automated Builds, Static Analysis, Unit Tests and Publishing:

Source Control

Source Control is the most basic need of software development – it is the absolute bare minimum. If anyone is writing any code it must go into source control. As legally contracted employees every line of code we write forms part of our business’s intellectual property and it is our duty to protect that.

Not only must code go into Source Control developers must know how to use the associated tools appropriately. With SubVersion this means: how often to update, when to commit, when to branch, how to tag.

TortoiseSVN is our SubVersion client of choice – it integrates into Windows Explorer. AnkhSVN provides integration with Visual Studio.

Automated Builds

Whenever a developer commits code an automated build should occur. We use CruiseControl.Net which provides us with an early warning system. It is not acceptable for a developer to state: “it works on my machine”. It needs to work on everybody’s machine! This is particularly true if more than one person is working on the same project.

One of our coding standards is that source control repositories should be self-contained. Any developer should be able to pull down a repo and build it as-is – all dependencies should be within the repo.

Breaking a build is not a big deal – we’ve all done it. We send around a picture of Billy Ray Cyrus – don’t break his heart, his achey, breaky heart! Leaving a broken build, however, is discourteous to your fellow developers. Builds should never be left broken overnight, or over the weekend.

Automated builds provide a heartbeat for the project – how many builds today? More than yesterday? How many broken? It is true that if there are lots of builds the server can send lots of emails – but this is simply handled with a subfolder in your Inbox. These emails should never be automatically deleted – why would you not want to know about a broken build? Use rules, or colour coding for filtering – never for blanket deletion!

Static Analysis

Static Analysis is the examination of code for correctness. This can happen according to various criteria; in particular we are concerned with Style and Design. The StyleCop tool can be used to enforce coding standards e.g. have you used casing and spacing correctly? The Code Analysis tab of Visual Studio projects replaces the FXCop tool, which checks for correct design, e.g. have you tested arguments for nullability.

Static Analysis can also contribute towards the Extreme Programming (XP) principle of Collective Code Ownership. This principle states that developers should be equally responsible for all code. There should be no concept of Dave’s class, or Susan’s subsystem. Any developer should be able to maintain any code. It should all look consistent to them and they should be able to hit the ground running.

Unit Tests & Code Coverage

Unit Testing is developer-led testing of methods and functions using a testing framework such as NUnit. It provides a safety net for change.

If I choose to make a change to the GetLastOrder method my unit test will ensure that it returns appropriate values and that it calls the correct helper methods. If such a test did not exist how could I be sure that I have not broken anything? Will it be found in system testing? Maybe, maybe not… Testers tend to see software as a black box; they can’t possibly know all the routes through code like a developer can.

A comprehensive suite of unit tests can allow refactoring (i.e. improvement) with confidence. Numerous studies have shown that bugs are cheaper to fix earlier on in the process. In Code Complete Steve McConnell introduces the General Principle of Software Quality: improving quality reduces development costs.

Code coverage is an indication of how much of your code base is being tested by your unit tests. 100% coverage is not realistic – some things, particularly generated or framework related, can never be covered – but the aspiration should be for as much coverage as possible. 80% is a reasonable target.

NUnit, Moq, NDepend and TestDriven.Net provide invaluable, integrated testing tools.

Publishing

The pinnacle of our hierarchy is Publishing – which encompasses generated documentation, wikis and technical specs.

Most business managers would probably be aghast to think that documentation should come last. Yet the Agile Manifesto states a pragmatic preference for working code over comprehensive documentation. Would managers rather have a working system or a 300 page spec that was out of date even before it was finished?

Good developers prefer self-documenting code. Using plain English to describe a method rather than obscure code-speak i.e. GetLastOrder(int customerNumber) instead of lastord(int n).

By adding XML comments to classes and methods good quality API documentation can be generated as part of the automated build process. GhostDoc is a tool that can assist developers in writing these comments. The Sandcastle Help File Builder can be added to your continuous integration process.

Rather than a stale monolithic specification wikis can be used to create living, breathing documentation websites. Maintenance is far less onerous!

Conclusion

So there you have it, my pyramid of software needs. Just like Maslow's you can expect to build higher unless your foundations are sound. No point going for automated builds unless you've got source control.

The pyramid is supposed to be aspirational - yes, it would be great to be at the top, but getting there can be a bit of a slog. My advice - take it easy, build one layer at a time.