Have you ever built a house? It’s an analogy often used when developing software. So, have you? Me neither, but one of the things that most people understand about building a house is you need architectural plans. Floor plans in particular will tell you the dimensions of each room, detail fixtures and electrical items, note finishes and construction methods, and so on. It doesn’t just tell you where a door is, but also which direction the door will open in. It means when the construction crew turns up, they don’t need to ask how many bathrooms you want, and where you want to put them. This is all perfectly logical. No one would be accused of stalling when no floor plans are available.

For some reason, this doesn’t translate to software development in quite the same way. Sometimes feature implementations will be requested without more than a description of an idea. Developers will receive it and have hundreds of questions, because an essential consulting and requirements gathering stage has been skipped, and there is no spec for them to implement.

Why does this happen? Mainly because like all analogies, it will break when stretched. Developing software is often not like building a house. Moving a wall is costly – it is easy to understand that because you can see the physical effort involved. In our analogy, moving a wall in software does not afford the spectator quite so clear a view – it can be difficult for someone without a development background to understand why the changes they’re asking for are complicated and expensive to undertake. After all, if repainting the walls is as simple as changing a hexadecimal reference, why should moving the kitchen to the back of the house be any more difficult?

Another problem that seems common is a basic misunderstanding about agile processes. Look up “agile” in a dictionary and you’ll see it described as flexible, nimble, acrobatic. This is what people understand when you say you’re agile, and not so much the idea of iterative development processes. “Well, they’re flexible” they’ll think, “we can always change it later”. And yes, you can tweak things as you go along, but putting the basement in the attic isn’t really a tweak.

Perhaps more importantly, there is a fundamental difference between commissioning your dream house and requesting a change on a software product. The former is often a deeply personal affair, in which the customer is willing to invest their time as well as their money. Getting a customer to invest their time in defining the exact behaviour they want their application to have appears to be much harder – after all they’ve outsourced the work for a reason. I’m told some companies will even reject customers who aren’t willing to invest their time in this way.

Some time ago, Steve Yegge wrote an absolutely brilliant blog post entitled Have you ever legalized marijuana? If you haven’t read it, please read it now. Go ahead, I’ll wait. Done? Good, isn’t it? Steve makes a very strong point in the article – that what seems like a simple idea, which at first glance makes perfect sense, may turn out to be completely insane when it comes to implementation. If customers write a spec they might see this – the process of writing the spec will force them to think about how it might all work, and they might quickly come to the conclusion that it’s not going to work. More often than not, however, the job of analytical thinking will fall to a development team. This tends to make sense, as this is something developers are well equipped to do, and which they are good at.

But what happens when developers have to think about how to move the basement into the attic, or their feedback isn’t given due consideration? Steve mentions something which isn’t necessarily front and centre of the article, but which I’ve found to be true:

Because that kind of shit happened at Amazon pretty much every week I was there, for almost seven years. (And astonishingly, we actually managed to launch at least half those crazy ideas, by burning through people like little tea lights.

You will burn out your developers. Working on insane projects will lead you to insanity. So not only will you have to deal with the logistical nightmare of working without a plan, suffer the delays and extra expenses that that will incur, and strain the relationships with your clients, you will also find yourself having to recruit more often (and consequently spending more time and money on training).

If you take away only one thing, make it this: if you set off without a spec, you will never know whether you’ve delivering what was expected. I know, I know – sometimes it feels like the way to go about a feature is to start coding and see what’s possible (I’ve done this myself). But even in a healthy agile environment, a spec will provide you with a solid platform to start off from. Spend the time to prepare a spec and discuss the issues around it upfront, and save yourself the strife.

Photo by Will Scullin via flickr.