Richard's BLOG

Category: IT Topic: The dangers of imprecision

Software development proceeds from a high-level, vague project vision to low-level, precise code. Most development methods, especially those based on the common mis-understanding of top-down I talked about in my previous blog, imagine the route from vision to code like this:



If, however, you know how to build precise models at a high level of abstraction, you can choose this route, instead, in which a vague project vision is turned into a precise model, which is then implemented:



Another way to see the difference between the two approaches is to remember the two kinds of detail I mentioned in an earlier blog: there's the kind of detail involved in adding precision at the current level of abstraction, and there's the kind of detail involved in changing to a lower level of abstraction.

If you do see development as the one-dimensional line in the first figure, you'll need to choose some level of abstraction at which to write your functional specifications (or whatever you call the specifications of what functionality the next release of a system is to provide).



Whatever level you choose, you'll face the following problem: your functional spec will necessarily be lacking some of the precision that the programmers will need in order to write code.



Consequences of this "precision gap" can include:

• programmers keep going back to business experts for clarification


• the system as built incorporates different rules from the ones the business experts imagined


• programmers invent the business rules

To overcome some of these negative consequences, IT departments are prone to add yet lower and lower levels of detail in their functional specs. As long as you believe development is a one-dimensional path, moving to a lower level is the only way to add precision to your functional specs. There's a downward pull on the level of abstraction at which you write functional specs.



Of course, if you understand that there are two kinds of detail, and that development is two-dimensional, you can choose to add precision to your functional specs without moving to a lower-level of abstraction, following the development path illustrated in the second figure near the beginning of this blog.