By nature domain understanding does not lead to specification. Understanding suggests design. A very important part of design is limits. When design is allowed to bubble up from understanding it’s easy to put the limit of the design into places that are logical for the domain. In contrast to design, requirement definition is limitless. The requirements gathering process typically goes on until someone says “I think we’ve got enough now”. That arbitrary stopping point becomes a design limit and hobbles further system development.
...
The solution is to write the requirements after the design is created so that the scope will be defined.
Monday, November 24, 2008
Design Before Writing Requirements?
Not a bad article, I agree with a lot of it, this was the best part:
Subscribe to:
Post Comments (Atom)
Posts
Interesting article. There is one giant leap that developers have to make for his system and it is step number 1 - Understand the domain.
ReplyDeleteI've been a developer for over 10 years now and I have really never understood the domain of the systems that I have written (at least not to a level that I would comfortable "running the business"). I don't think there are very many developers who stay in the same domain long enough to gain that kind of knowledge.
You think the buy in needed for writing requirements is big, just wait until you have to tell management that we need to train the developers for the next 6 months before they can start designing the system.
Great point, Matt. It reminds me of an article I read, comparing software methodologies that include hiring great developers, to a recipe for winning track races that says:
ReplyDelete1) Meditate night before race
2) Wear lucky shorts
3) Eat and hydrate well
4) Run really, really fast
5) Win race
So yes, if you know the domain well enough to run the business, that is a big advantage. Joel has written about that, too--that is why so many developers want to start a business selling coding widgets and bug-tracking software.