Zen & the Art of C/SIDE Development

Although I left out some less relevant stuff here and there, this blog post is actually based on a true story. It is meant to illustrate how rethinking the structure of an application can improve its usability, maintainability and flexibility – all at the same time.

Imagine a simple document-style entity type. It has a No. (probably based on a No. Series) as its primary key, a Description field and a Status field.

Pretty soon, it is decided that the Document table should also keep track of which developer is associated with each document.

Instead of having developers periodically check for changes in the Status field themselves, it is then decided that they should receive an e-mail whenever the field’s value changes. Although the developer’s e-mail address is stored elsewhere, it is displayed on the document card.

Pretty soon after that, another role is introduced. Obviously, this person should also be informed when the Status changes.

This is when the initial design is starting to come apart at the seams:

• There are plans for adding even more roles, compromising the usability of the form
• People who are not formally involved in the project would like to be notified, too.
• Some people who are formally involved are getting tired of being spammed with status updates.

To deal with this problem (which, in reality, was a bit more complex than in this example…) we introduced the concept of subscribers: a list of people (for each document) that wish to be kept "in the loop".

By default, anybody in a formal role (i.c. the developer and project manager) gets added to this table, but can be removed. Interested third parties can easily be added as required.

Please let me know what you think about this approach!

P.S.: As usual, I may have cut some corners for simplicity’s sake (e.g. if the value in the developer field is changed, should the system remove the old developer from the subscribers table?). If you see more serious flaws, I’d be more than interested to hear from you!

FOLLOW-UP

A little follow-up on the post above, in response to some feedback that I received from Luc van Vugt (http://dynamicsuser.net/blogs/vanvugt/default.aspx). Thanks, Luc!

As I said, at the highest level, my post was meant to illustrate how simple changes in an application’s structure can bring significant improvements. At a slightly more detailed level, it illustrates a pattern that is not uncommon in steadily growing applications.

In the example above, similar groups of fields (i.c. User ID, Name and E-Mail fields) are added to an existing application. The presence of such groups should trigger us to consider “tilting” the data model: converting each group into a record in a new table. This way, you’re turning “horizontal growth” (more fields; more code; more complexity) into “vertical growth” (more records, same code, same complexity). Makes sense?