August 4, 2012

...Learn TDD with Codemanship

Back To Basics #7 - Software That Can't Be Put To Use Has No Value

This is the seventh post in a series of ten exploring basic principles for software development while trying to avoid the usual sales-speak and marketing hype that accompanies this sort of thing, so hopefully software noobs can gather some simple insights into why we do what we do.

Here's a little ditty that tends to get left out when we discuss the principles of software development.

Arguably, it seems so obvious that we shouldn't need to include it. But an experienced developer will tell you that it all too often gets overlooked.

You cannot eat a meal that's still in the restaurant's kitchen in pots and pans. You cannot listen to a pop song that's sitting on the producer's hard drive in a hodge podge of audio files and MIDI. You cannot drive a car that's still on the assembly line.

And you cannot use software that's still just a bunch of source code files sitting on different people's computers.

Software, like food, music and cars, costs money to make. In the majority of cases where teams are doing it commercially, that's someone else's money. If our ultimate goal is to give them their money's-worth when we write software, we really need to bear in mind that the value locked in the code we've written cannot be realised until we can give them a working piece of software that they can then put to good use.

Typically, the sooner the customer can get their hands on working software that solves at least part of their problem, the better for them and therefore for us, since we all share that goal.

This has a number of implications for the way we develop software.

Firstly, in order for software to be released to the customer, it needs to work.

Teams that have put insufficient care into checking that the software works - that is, it does what the customer needs it to do, and does it reliably enough - will likely as not find that before their software can be released, they have to go through a time-consuming process of testing it and fixing any problems that stand in the way of making it fit for its purpose.

It's not uncommon for this process of "stabilising" the software to take months of extra intense work. It's also not unheard of for software to fail to stabilise, and for releases to be abandoned. Because problems can take many times longer to fix when we look for them at this late stage, this turns out to be a very expensive way of making the software good enough for use in the real world.

It makes more sense economically to take reasonable steps to ensure that the software is working while we're writing it. We write a little bit, and we test it, and then we write a bit more and test that, and so on. If we're working in teams, we also integrate as we go, to make sure that the whole thing works when we incorporate our parts.

Secondly, it's entirely possible that, if we effectively prioritise the customer's requirements and tackle the most important things first, we may create software that would be of real value if it were put to use before we've built the whole thing.

But who is best placed to decide if that's the case?

It's the customer's problem we're trying solve, and the customer's money we're spending to solve it. Common sense dictates that the customer should decide when to release the software to the end users.

Our job, as developers, is to be ready when they make that call.

We have a responsibility to ensure the software is always working, and that we integrate our work into the whole as often as we can so the risk of important code being left out of the finished product is as small as possible.

In a learning process, for us and our customers, releases are likely to be frequent and the amount of change in each new version of the software is likely to be small. It's therefore of paramount importance that we can release as frequently as the customer requires so that they can more quickly learn about what works and what doesn't in the real world. Failing to do this very significantly reduces our chances of hitting the nail on the head eventually.

Posted 9 years, 3 months ago on August 4, 2012