Difference Between Specification And Implementation

Question: Along which dimensions and to what extent should one allow degrees of freedom for implementation in the specification?

Examples of constraints a specification puts on an implementation include:

• Performance requirements
• Programming language
• Coding standards
• Architecture/Platform
• Installation date

I know these don't necessarily fit into an academic definition of "specification," but they occur all the time in everyday software development. There are constraints that are set up front on the teams tasked with implementing a solution.

The question is one of distributing responsibility. What constraints should be set by the customer, usually "up front" (I'm calling this the specification) and what constraints or rather solution details should be determined by the implementers?

--JeffMantei

---

I don't think I understand the question. The specification should say as little about implementation as possible. It might be legitimate for a spec to say "Must be written in C" or "Must be targeted to Solaris running on a Sparc", but what possible reason could there be for saying much more about implementation in a specification?

I assume I'm missing something. --GarethMcCaughan

---

If you're looking for a rule to govern distributions of responsibility and decision-making privelege, I can't think of any simple ones except: "It's the customer's money". I view it that any paying customer gets to call as many shots as he wants, although this may make the project so unattractive to me that I cannot work on it.

Do we need rules for this, or do we need collaborations between us and customers in which the lines of responsibility can drift depending on practical and human needs?

Customers usually hire developers to do what they (customers) don't know how to do, or don't have time to do, or don't want to do. I like it best when I am called upon to do something the customer doesn't know how to do; otherwise I just feel like a pair of (possibly dirty) hands. -- WaldenMathews

I concur. The developers are the experts, and a customer who tries to do the developer's job deserves to lose; but if the customer insists, that's their right. (And it's the developers' right to quit, unless the contract forbids it.) Of course, sometimes the customer is the developers' boss and is reasonably expert too; that changes a bunch of things. --GarethMcCaughan