Richard's BLOG

Category: IT Topic: Book on domain modeling

My co-authors and I have reached an important milestone in the writing of our book. We've now got a complete draft of all chapters.

My tasks for next week will be:

- find a displacement activity

- tell myself off for engaging in displacement activity, and stop it

- find a new displacement activity

- reward myself for being so busy

- notice I haven't actually achieved anything useful

- find a new displacement activity

- finally admit that displacement activities aren't the same as writing the book

- patiently check the details of the case study in every chapter

- find a displacement activity

- tell myself off for engaging in displacement activity, and stop it

- find a new displacement activity

- admit again that displacement activities aren't the same as writing the book

- go through whole book, filling in the few remaining missing bits.

You can see where the phrase "struggling artist" comes from !

You might already be on our list of people we plan to ask to review the complete manuscript but, if you'd like to review the book, email me just to be sure (if you don't already have an email address for me, please use richard at inferdata dot com).

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.