After adopting a new design process philosophy, and implementing a trial project using it, a design anti-pattern has presented itself.
Document Driven Design – this anti-pattern is the practice of allowing whatever document template is mandated, drive the actual process or practice of design.
It is common in the enterprise space, especially post Sarbanes-Oxley where such documentation is as essential for passing regulatory audits as it is for constructing application systems. Sometimes enterprise management get confused as to which is the primary objective. While I haven't read the federal register to determine what actually is required, many organizations have followed the consulting firm model, and developed a documentation framework for software projects that is mandatory.
I would expect that organizations that are towards the higher end of the capability maturity model use templates that are reflective of their already mature process, but organizations that are more steeped in chaos may be tempted to produce document templates that are an amalgamation of several different processes, thinking that those responsible for authoring those documents will know how to complete them. I have seen that this is not the case, and it can cause the aforementioned anti-pattern, that is reflected in the following statement: Design is complete, when the document is done.
As I said, I realized this after trialing a new design philosophy. New philosophy has 5 steps – initiate, decide, articulate, analyze, review. Articulate is the step where the the first draft of formal design documentation is created. The team had done fairly well, following the requirements of the philosophy until this point, and when they got there, we tripped over the template. Boom! Instead of figuring out what needed to be articulated, we attempted to cram all of the decisions we had made into the existing template, and became confused and the result was frustration. We got to the review step, and questions and accusations were flying. I had a great deal if trouble figuring out what went wrong.
What was the problem? Template thinking trumps philosophy! Why? I suppose that this is an instance of transposition of the familiar.
Now I realize that I have a challenge – that to support our new design philosophy, I need to construct an "articulation template" that can inspire innovation and help the team with the remaining steps of analysis ( which in my philosophy is impact analysis) and review.