[Originally drafted in March 2010, published February 2011]

For many decades now, developers and IT departments have been at the receiving end of a lot flack. Flack stemming from the fact that many software projects cost more than originally estimated and take longer to reach production than previously thought. Typically, it’s the fault of the folks near the bottom of the tree: the developers or the IT department. This blog post is a tale of woe that highlights the blame culture that we live in and how this author believes that blame to be misdirected, at least in some cases.

Most software projects have some sort of plan, a list of activities, a product backlog, user stories, perhaps even a schedule. Regardless of your religious view in the waterfall or agile space, you will have requirements noted down somewhere using whatever technique floats your boat. You may also have an “end date” (aka a go live date) that is either dictated by some form of time estimate based on the list of activities or, worse, by a third party. Invariably, you may not have a lot of say in the estimation process…you have to hope that the person is reasonably good at estimating how long it will take a somebody else to complete a task. Remember, that person is estimating how much time somebody else needs to complete a task: a task in a domain they most probably know very little about (“stick a button on that form there, how hard can it be?”)

Thinking about scope: can you produce a flowchart outlining your current process, the process that you want a magical application to replace? If you can’t produce a flowchart, how do you expect other people to understand the start point, the processing and the end point? You can expect some help from your developer, programmer or system implementor when it comes to documenting your current workflow; equally you can expect some help from them when it comes to documenting your requirements. However, don’t turn to your developer, programmer or system implementor and tell them that you don’t have the time to document the requirements or document the workflow. If you don’t have time to tell us what you want in the first place, we know (from experience) that you’ll not have time to help us with user acceptance testing later on in the project – assuming we can build a system worthy of user acceptance testing in the absence of any real requirements.

All too often developers and IT departments have been getting it in the neck for project failures. However, little has been said about the fact that the blame really lies with those further up the project hierarchy. Failure to provide adequate work scope / definition results in confusion and the potential for large amounts of scrap and rework. Developers don’t mind throwing code away as a result of refactoring, however they do mind shelving code because it has suddenly become redundant or is now not part of the solution.

In a recent current project I was told “we don’t have time to write a specification”. However, we do have the time to overrun by many months and we do have the budget to fund the additional development and to cover the opportunities that are lost. With no end in sight, developer morale takes a hit, they lose direction. Similarly, there can be nothing worse for a developer to be on a project where s/he doesn’t know what they are meant to be doing? And worse, if they do find out what they are meant to be doing, to have it change from one week to the next. Or even to have it [the glimmer of hope, the taste of the requirement] change from day to day.

In the absence of a specification, feature creep is inevitable. Development cycles feel, and often are, endless. Even with an understanding and helpful client, the absence of a specification is a golden ticket for those who want everything from the system. Specification-less projects suffer from feature creep and work scope additions. All of the “nice to haves” suddenly come out of the woodwork. And because there’s little in the way of contractual documentation in place to lay down the law or draw the line in the sand, there’s nothing you can do apart from argue your case against adding features. The time you spend arguing your case, is time you’re not working on the project, you’re not progessing the project towards completion, the delay gets worse. Mind you, perhaps it’s a good thing that you’re not working on the project, after all, do you know what you’re meant to be doing?

Software development is a complicated process.  Unstructured and unproven time/budget “guesstimation” just doesn’t work in this industry.  You can’t say to software developer “two weeks” to write an enterprise class system that replicates the functionality of commercial of the shelf software costing many £000’s per license.  Two weeks is how long it might take you to cut’n’paste a spreadsheet together…it’s hardly long enough to develop all but the most simple functionality.  In the absence of a specification, database schemas are an ever-changing beast.  In most data-driven applications, the database schema is comparable to the foundations of a building.  The foundations are not something you want to change half way through the development.  Granted, clever people have written applications with dynamic database schemas…but they weren’t written in two weeks, or part thereof. 

After the database design, there’s the user interface.  Yes, it is easy to drop a button on a form!  What’s not so easy is what that button does when you click on it.  Anything beyond MessageBox.Show(“Hello, world!”); is where the time is spent.  I’m grateful to have seen multi-page specifications for the action behind a single button – if you can find somebody willing to invest the time and effort in writing such detail, the payoff is amazing. However, such people are few and far between. In today’s day and age, agile is where it’s at and user stories are King. Ultimately, it’s an emotive topic and one that I will not debate here (although you are free to discuss in the comments) – I don’t mind how you capture requirements, as long as you do.

Software developers struggle to work with “what’s in your head today”, knowing from experience that it will change tomorrow. Even in the agile world, there has to be an element of commitment: if you change your mind day after day, you’ll get a reputation and folks will end up using baseball bats to extract requirements. That’s not a good look, trust me on that. Oh, and don’t take the picture too literally: don’t do things on a handshake, that doesn’t work either: put something in writing, a contract, something that sets the scene and defines the lay of the land.

Requirements: however you document them – they are the light at the end of the tunnel for you and for the developer / development team. If your developer / development team ask you for “better requirements” very early in the project (or, shoot, even at the very start of the project), don’t dismiss it. Listen to them, they probably have a point. They are the folks who’ll be writing the software and they are the folks who’ll struggle to prepare a deliverable based on incomplete or inaccurate scribbles on whiteboard or sheets of paper.

Requirements: abuse them at your peril. In the absence of requirements, prepare yourself for a bottom-less pit that will consume time, money, other potential projects/opportunities and the morale of your development team.

Considered Reading