Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to explain why the specification must not be changed during development period to the new planning department employee.

share|improve this question

migrated from Jul 12 '11 at 12:28

This question came from our site for professional and enthusiast programmers.

Programming against a moving target is half the fun! – Anthony Pegram Apr 23 '10 at 2:27
I'd say must is too strong a term. A specification is a blueprint, but sometimes there are very good reasons to make changes. – WhirlWind Apr 23 '10 at 2:32
"Walking on water and developing software from a specification are easy if both are frozen." - Edward V Berard – Jason Hall Apr 23 '10 at 3:42
most specs change, just let them know that their changes will most likely affect the deadline. At my place of work once we are giving a spec and a change is needed they must give us a full outline of the change, and we submit the time it will take, and they either accept the change or don't (or make us stay late) – Johnny Quest Jul 12 '11 at 12:33
If the specification needs to be changed, either because the requirements changed or because it was found to be incorrect, then the specification should be changed and as soon as possible. Just make sure that the cost of the change is known to all parties. – user16764 Jul 18 '11 at 22:04
up vote 15 down vote accepted

A specification nearly always changes during development for any but the most simple of projects.

The reasons are:

  • Development or more likely integration testing of the project uncovers things not noticed when original spec was done - from edge cases to major facets. E.g. developer notices that out-of-order message confirmations might arrive.

  • Real world condition determining the spec are not frozen. E.g. a new financial product is created which needs to be added to straight-through processing spec.

  • Deadline pressures result in pruning of features.

  • Additional stakeholders to the project are discovered (e.g. midway through the project a similar project is discovered in a different area, and common subsystems need to be centralized/shared - this happened to me midway through 2-year-long project resulting in major re-architeching).

  • Additional sponsors of the project have new spec requirements (one of the most famous examples is the history of development of Bradley Fighting Vehicle).

As to why the spec changes have adverse effect (you can't say "must not happen" since as you can see there's plenty of reasons they do, nearly all outside of your control and many for a good reason) -

  • Spec changes result in code changes, distracting you from completing the project parts that aren't written yet (as we all know, and evangelized by Joel Spolsky, focus changes are very bad for developers)

  • Some spec changes (sometimes seemingly VERY minor) might result in the need to completely re-engineer/re-architect the system since a choice between 2 architectures was made based on an assumption taken from the spec.

  • In case of TDD, a large chunk of work put into tests might be voided.

  • If the spec changes come from additional stakeholders as noted above, they might be contradictory to existing spec, resulting in significant decrease in product quality (see Fighting Vehicle, Bradley).

  • The spec change might violate some existing business requirement that the changer/requester might not have been aware of or cared (this is really the same as last bullet point).

What these all amount to is of course extended (sometimes significantly) delivery date of the project and potentially increased likelihood of defects.

For the best ever example of how a minor change in the spec can create extreme problems, I have 3 letters for you:


All they did was change the spec to say "must work after year 2000".

In addition, in some situations it is indeed the case that the specification MUST not change (as opposed to "should not change without good reason"):

  • Part of the spec is (or is dependent on) a specification of an external system that must be interfaces with.

  • Part of the spec is (or is dependent on) a hardware that the system is implemented on.

  • Contract requirements with a client (though the limitation is strictly speaking on changing the spec without working through the changes with the client first and changing the contract, as opposed to merely the fact of the change)

  • A system may need to meet specific legal or regulatory requirements regardless of customer preference. Examples: credit card encryption, protection of tax data.

share|improve this answer
Is ok; I stuck it back in. – WhirlWind Apr 23 '10 at 2:56
another reason for not changing the specs, which is also paradoxically a reason for changing them, is legal requirements. Many pieces of software deal with that. As long as the laws they have to content with don't change, those requirements are static. As soon as they change, the requirements change. And that is completely out of the hands of the development team or their customers (unless those customers are the people who're enacting those laws directly, which is exceedingly rare). – jwenting Apr 27 '15 at 4:30

Prohibiting changes to the spec during development is ideal for the programmer, but it's not realistic in a real-world setting. People will always want to make changes, even when the thing is shipping out the door. It never stops. And some of those people may be signing your paycheck. The more they care, the more they think about it, and therefore the more often they want to revise the design. You have to be able to tolerate changing the design before completion, even if it means starting over.

The important thing is to clearly communicate the consequences of changes so that everyone has realistic expectations of the design process.

Changes have to be properly discussed, and the person in charge of the thing needs to have a clear understanding of what impact the changes will have on the delivery date. To get that, he has to talk to the developer. However, since an ongoing discussion of changes will inundate the developer and keep any real work from happening, the changes have to be queued and discussed at planned, infrequent intervals. That's what you hope, of course.

Ideally, you instruct people to make a note of the changes they want to make and have them bring it up in the weekly/biweekly/monthly/whatever coordination meeting. During the meeting each change request is discussed, including a discussion of the underlying modifications that will need to be made in order to implement the requested feature, and therefore the effect on the completion date. Once the "cost" of the change is established, then they can then determine whether or not to include it.

The important thing that this process introduces is the notion that each change has an associated cost, and the cost is generally higher the further along the project has progressed, since more work has to be duplicated. People who don't work in development usually have no idea how much a change will cost; the only way for them to tell is to propose it and gauge your reaction. Creating a well-defined change review process will help both them and you out.

Note that programmers tend to be either extremely optimistic about the how easy a change is to make, or extremely pessimistic about how impossible it will be to do. Try to figure out what you are by comparing your original estimates against the results, and adjust accordingly.

share|improve this answer

Perhaps it would be better to say that the specification must not change without a valid change request and process. Requesting a specification change has effects on schedule and cost, so these must be factored into the approval.

Given that there is a proper change management process, there is nothing "wrong" about changing specifications, but it is likely to be very expensive, so your customers may not be too happy. You can protect them from themselves by trying to get some good requirements and specifications up front, so that fewer changes are needed.

share|improve this answer

The best analogy I have is to compare it to building a house. The architect draws up the plans, and then comes up with an estimate, the customer then agrees (or not) to the plan. If the customer wants an extra bathroom put in then the work stops, plans have to change, a new estimate is done and the customer agrees (or not).

Writing software is no different. once the agreement has been made (after the design and estimate) then if any changes need to take place then work needs to stop to be able to make new plan, new estimate then get them approved (or not) and then the work resumes.

wherever I said or not means either the project goes on without the new changes. Of course there is always the time and materials to come up with new plans and estimate.

share|improve this answer
This is a poor analogy. We write software because it is a lot easier to change than a house, at least when calculated on a per-user basis. Software is so much easier to change than a house that about the only thing they have in common is that both are human activities. – kevin cline Feb 17 '12 at 20:58

protected by MichaelT Apr 27 '15 at 1:11

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.