Collective Wisdom from the Experts 35
Blurring the lines between requirements and specifications leads to the wrong
people making the decisions. You either end up with the software developers
making decisions about what features are important to a user, or with a soft-
ware project manager telling a developer how to structure code. Either way,
the result is a poor final software product.
Developers aren’t usually out talking to customers, users, marketing, sales, and
potential partners, trying to understand what new features are most important.
On the other hand, software project managers usually aren’t skilled developers
who understand how best to implement a feature, and how their untrained,
although well-meaning, specification suggestions would affect other aspects
of the product. Each group has a unique skill set.
Having good requirements that describe the problem you are trying to solve,
and why it is so important to solve this particular problem, lets the program-
mer be more flexible, efficient, and motivated during the development process.
Coders can make independent design decisions as they work on the problem
and understand it more thoroughly. They should only be bound by the tech-
nologies they have chosen to use, not by strict, brittle specifications created by
a nonprogrammer.
Specifications still need to be written, but they will change. Have you come to
the end of the product development cycle and only then fully understood how
this product should have been built in the first place?
Keep the what you are trying to build separate from the how to build it. Then, let
the properly trained team member make decisions based on his/her project role.