The 15 Minute Rule Of Software Development

I talk a lot about how having a spec is a critical component of software development. But how do you know that your spec is good, and that it has been developed enough? Simply put, how do you distinguish between a good spec and a spec that is lacking?

This problem had confounded me for a good bit of time, because it’s hard to create a rule surrounding spec development. Since most developers (myself included) are also generally bad at developing good specs, it becomes even more difficult to create such a rule. However, I heard a great adage from someone recently that I thought summed up how developers can see specs nearly perfectly.

If it takes more than 15 minutes to determine what it is that you’re building, the spec wasn’t done properly.

Before we get into what I mean, I want to add this caveat: this is a generalization, designed to illustrate rather to inform. I don’t recommend people buy timers and set them to 15 minutes, and at 15:01 send the spec back to the product team. That’s not what the point here is.

The point here is that developers aren’t usually spec designers, at least not when it comes to the actual development. When code is being written, the spec should be settled. There should be some kind of wireframe or description of the functionality required. This need not be in an abstract requirements document; it simply needs to be able to communicate effectively to the developer what the person who wrote it wants.

Having a spec that is clear and able to quickly tell a developer what is wanted allows the developer to spend more time on other things that are important, like designing the backend, implementing the functionality, testing and the front-end artwork. These are the true tasks of developers. Additionally, having a clear spec from the beginning helps ensure that the finished product will more accurately meet the intentions of those requesting it. This makes for happy clients, internal or external.

In order to employ this rule, however, there is a caveat: the 15 minute rule applies only to determining what is being asked for. It does not apply to debate over architecture, design, implementation, artwork, or other aspects relating to implementing the spec. It relates only to debate over the spec itself. Also, in cases where the developer is called to assist in developing the spec, obviously the rule doesn’t apply.

Making the spec better is a critical component of making development work. This rule provides a baseline, and should help produce better specs and ultimately, better products.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Stuart Herbert (@stuherbert) wrote at 3/18/2010 7:18 am:

Interesting idea, and I’m sure it’ll really help folks when they’re reviewing a spec to make sure they haven’t created some behemoth from hell :)

But I’d always recommend an alternative test. If you can’t create appropriate acceptance tests to prove that the developer / supplier has met the spec, then the spec isn’t finished.

Best regards,
Stu

Eli White (@EliW) wrote at 3/18/2010 8:39 am:

Nice post Brandon; however, it seems to be very targetted to a specific development environment.

I’m used to working in situations where the developer is involved in creating the spec in the first place. In fact, I’m a HUGE fan of this practice as it really leaves the ‘spec’ phase with a product that everyone understands and has agreed upon. In this case, there is no idea of tossing the spec back, because the developer helped create it and knows exactly what it is.

More importantly though, is the idea of development on small agile (small ‘a’) teams, where specs are loose and changing at all times anyway. Where you just throw code out there and iterate as needed. In which case, there isn’t really a formal spec perse anyway.

Sebs (@phptestfest) wrote at 3/18/2010 12:47 pm:

With scrum you have this process in several parts:

weekly meetings to get a leverl of uderstanding that everyone can say “this is big” or “this is small” which leads to a first level of understanding
a meeting where we take the story and get all acceptance criteria
and a design meeting, which leads to the final level of understanding.
And for big ones we exceed your 15 minutes, but maybe becasue we are mixing up things

Chris Roane (@mtprogrammer) wrote at 3/24/2010 10:57 am:

For me, the importance of a spec document is that it covers the specifics, which prevents the specifics from becoming monsters. I don’t mean tiny specifics, but specifics that vary the amount of time that it will take to develop that part. For example, a photo gallery is a horrible description, because it does not cover exactly what the client is thinking for the gallery.

I like this article! It goes a long with my experiences. I may blog about this on my site.

Copyright © 2023 by Brandon Savage. All rights reserved.