Pragmatism – design assumptions are about pragmatism. Pragmatism is the easiest path to good enough. If I already have tools available that will allow me to do the job "good enough", why would I go buy and learn new tools? If I already have a team that supports 5 applications written in Java, why would I build a new application in C# or Ruby? If I have an application written in C# using HTML/AJAX/Jquery/CSS to do user experience, why would I build my next screen using Silverlight? Why would I go out of my way to add cost, time, and risk to a software project? Simple answer, I wouldn't.
Design assumptions, are about documenting the "status quo". They are typically written before I have thoroughly understood requirements, in fact, they are not about the requirements. They are about everything but the requirements. They are statements that require a compelling reason to change. That reason should be related to I can't meet the requirements unless I undo this assumption.
Design assumptions can also be used to document constraints that come from the organization or the project. For example, the normal time frame for establishing a new test environment is 30 business days. The desired time frame for delivery of these capabilities to production is 3 months. The project budget is $120,000. Only approved open source software can be incorporated into application build.
These assumptions and constraints have the following properties:
- Known apart from the software requirements.
- Express inertia, obstacles, or guardrails that the project must contend with.
- Cannot arbitrarily be removed, changed, or overturned.
Documenting design assumptions is important, because they communicate to the team (especially when bringing new team members on board) a starting point for design. We are doing it this way, unless there is a compelling reason to change. We are constrained by these factors that can only be changed for good reason. They also communicate to your customer (who may be reviewing your design) some things that they have the power to change if it makes a difference.
When we make design decisions to comply with time or budget constraints, it may mean a reduction in quality or sustainability. When organizational constraints make it cost more, or take longer to produce the same solution, we can decide whether the constraints are reasonable.
Finally, in a project oriented culture, assumptions are a convenient way to "roll" design decisions forward release by release. If your organization maintains documentation by project, rather than by software product, it can be easy for core design decisions to get lost after a few releases, especially if the development team has substantial turnover. After a a short period of time, nobody remembers how or why we decided to organize things, and new features can be built contrary to the original design principles that were followed, only because the people who built them didn't know there were principles (or couldn't see them clearly in the code).
