Keep the Technical Design Specification short to stay creative

Keep the Technical Design Specification Short To Stay Creative

Photo by Tobias Toft

Our first time enterprise clients keep reminding us through their projects that we should read their technical design specifications (TDS). Whenever a detail comes up through the project, they become furious and tell us that this particular issue was on the page x of our 100 page TDS. When that happens we remind them that no, we only use their TDS as a reference but we follow the one that we’ve written ourselves which is only 3-5 pages long. We work out the details as the project moves along. We only focus on the few design problems that need to be dealt with immediately per development cycle rather than many hypothetical ones that are brainstormed in advance.

In fact that is the purpose of the initial meetings that we have with our clients. To understand the problem they are trying to solve and propose a simple solution which often takes up only a few pages of descriptions, bullet lists, and diagrams. This document defines the general direction of the project and defines the objectives for the first 3 or 4 development cycles. After each development cycle, the results are once again reviewed and if there are any changes that need to be made, they are decided and agreed upon. This is the very essences of lean and agile development.

We believe that lengthy TDS documents take away flexibility and creativity. They are counterproductive and bureaucratic.

The first time enterprise client remain skeptical until we deliver their project successfully. That’s when they become our good references and recommend us to others.

Why is a TDS so “tedious”

So why is an enterprise TDS so tedious to read and write? There are multiple reasons:

Analysis Paralysis

First is the analysis paralysis. It is human nature to try to minimize the risks by over planning a new project. In enterprise there are all kinds of compliance and liabilities that need to be met and addressed. To prevent those, a product development team tries to minimize the possibility of things going wrong. However product design and development isn’t the same as production. A company may have all kinds of protocols and guidelines in place for mass production, but creating something out of nothing requires focus and creativity. Focus on solving a specific problem in the most elegant and minimalist fashion. That can only be achieved through many development cycles where each product release focuses on solving a small and well defined set of problems. Throughout the development cycles the compliance and liabilities can be addressed and adjustments can be made to the design. In some cases obsolete rules and regulations can even be challenged or put to test once again to see whether they still serve a purpose while using the new and modern product.

Keeping the System Analysts Relevant

Second, the TDS documents are often written by dedicated staff and system analysts. It would be very hard to justify their role if the end document was only 3 to 5 pages long. However a 100 page document would make them appear as valuable members in the company and possibly impress their bosses too. This scenario especially happens when developing an Enterprise Aspiration App. System analysts are key actors in the Water Fall model and Agile Development made their role redundant. It may sound a little harsh, but some software architects even believe that system analysis is dead; Agile Development killed it.