I want to explain why the specification must not be changed during development period

Question

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

Is there any cool document that does this?

Answer 1

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:

Y2K.

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)

Answer 2

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.

Answer 3

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.

Answer 4

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.