The Limits of Specifications

Most descriptions of software development processes begin with the idea that you have some notion of what you want to build. The degree of specificity varies. At the least precise is the very loose, one-sentence story point or “product idea”, and at the other end of the spectrum is the Specification. Modern, agile approaches tend to the former and more traditional approaches tend to the latter.

But both stress the wrong thing.

I suppose I’ll need to justify that remark…

Let’s start at the Specification end of the spectrum. Specifications take on many forms — requirements elicitation and enumeration, use case analysis, UX mock ups. All of these can be very useful, especially during the early stages of work where you are trying to (roughly) scope out the work and effort involved.

The Specification is handed to the Developer, who then Develops the Specification into Product. Depending on the company and the process, the developer may not even have had a hand in the creation of the Specification, but in any case must interpret the specification to actually create the code. Developers make hundreds of decisions in the course of an implementation, and many (if not most) of them, have to do with deciding the minutia of how the product or feature will behave. In essence, all of these are product design decisions.

Interpretation == Product Design

This is where the emphasis on initial specification is misguided. Well, not completely misguided, but it is at best unbalanced. If a company pays close attention to the specification process, but then does not train the developers to understand the domain of the product, then it is compromising the product design inherent in the hundreds of behavioral decisions made by developers every day.

Agile methodologies do better than BUFD methodologies in this respect because they explicitly have a user advocate on the team. (At least officially — my understanding is that the user representative piece of agile is often compromised in practice.) This gives developers someone to go to make decisions when they are in doubt. While inefficient, this is fine. However, a user advocate isn’t thinking in terms of the code because that is the developer’s job, and over time that can lead to unnecessarily complex code because each decision is considered in isolation and not as part of an overall implementation strategy.

So what I’m advocating here is that developers on a team must have a deep understanding of the customer needs and domain of the product, and that this understanding is at least as important as having a specification for the feature/product at the outset. A company must spend the money and effort to get their developers this understanding as well — it won’t just happen magically through osmosis or something.

Sadly, too often I think the industry views developers as simple technicians taking people-speak and turning it into code — and I think that a lot of developers look at things that way! Too often we hear that the requirements or the specifications were incorrect or incomplete as if that were not, at least in part, the developer’s responsibility (whether or not they are a full-time employee or a contractor).

The software development process is too large and complex (at least for non-trivial problems) to make it practical to isolate domain knowledge with business analysts or systems engineers. Domain knowledge must permeate the entire organization.


About jeffkotula

Software engineer, musician, and so on...
This entry was posted in design, Process, requirements, Software and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s