Software Design cycle and cost to change.

Just thinking about some of the issues within the software design cycle and the cost of making changes.

The simplest start point for the design cycle might be:

1 Start working on design
2 Hack up prototype (to help clarify requirements)
3 Display it to the client in some form

At this point what are the implications of choices you have made or missunderstandings between you and the client?

I would suggest that at this point the cost of reversing a decision in your head is relatively small. ( It probably has a few high level dependencies that have to be refactored and untangled but its essentially still a clean slate)

Depending on how many of the clients people have seen the prototype and talked about it ( blogged about it with screen shots??) will depend on how the ideas you have communicated have become semantically embedded in the clients understanding of the project.

Now begin a cyclical design/build/show process. At each turn of the cycle, the client gets more engaged ( you hope) with the semantics of the solution.  What is the cost to add or remove these semantics?  Whats the cost to "tweak" them?  Whats the cost to "improve or clarify" them?

At some point the project is moved into beta testing.  At this point the cost to change semantics in the project gets heavier.  Additions of new semantics is cheapest, changes to/replacement of existing semantics are complex and removal of existing semantics is highest.

Once the project moves into general use by the client(s), the cost to change the semantics of the design are significant.  Time in re-training, time in learning new ways to talk about tasks and processes, time to update documentation and remove old references.

The only way we currently know to do this is to explicitly replace the semantics with a completely new semantic network ( change the version number and attach the new ideas to the new version number)

So whats the idea here?

Like everything once we abstract it, we can manipulate the abstraction. 

We can re-arrange the size of the costs and the time that we need to pay the cost by manipulating the way the semantics are exposed to the client and how "concrete" they are to reduce the way the client absorbs them early in the lifecycle of the project.

Rather than describing the project features with a specific name like "Print Receipts" use a vaguer abstraction such as "Feature to print receipts from a sales transaction".  This reduces the specificity of the semantic network that can be built from the information and keeps it malleable. Once you start reducing the words it takes to describe an idea, the term gets more and more semantically specific and takes on a more and more defined role in the semantic network that can be formed from the semantic soup of the whole design.

By keeping the semantic network loose and malleable, its much cheaper to change. However the cost in complexity of the network is higher.  I.e the client has less clarity about the semantics of the design. (Some good, some bad...depending on the client I guess)

That being said, you as the designer need to have clear semantic network... so does this help you or bog you down in vague language that you will be tempted to clarify and thus harden the design?  Tradeoffs are a bitch.

Needs more thinking.