What drives development?

I have seen a number of different drivers for development endeavours:. Data driven, model driven and user interface driven. I believe that for the purposes of end user development, the interface driven development method is most appropriate. In fact, I think it is the most appropriate not only for end users but for the average application programmer as well.

Database driven development (bottom-up)

Entity Relationship modelling is a very powerful modelling language. So powerful in fact that since its inception it has shaped the way we build applications for the years to come. In this method, the entities required to solve the business problem are derived from the business case and data to be stored. These entities are modelled in an ER model, that ER model is then used to create the database.

Business objects (often eerily similar to the entities in the database) are created. These objects are then made manifest on the user interface through traditional programming means. In some cases, we forgo the objects altogether and bind the user interface directly to the database. We have this method to thank for user interfaces consisting of data bound forms, grids and master-detail forms.

This has held us in good stead, and for many simple applications it is all that is required. However, starting at the database (entity) level is wrong. It is too far removed from the actual manifestation of the system to the user (and thus, the user requirements). The use only “sees” the user interface. Thus, as far as the user is concerned, the interface is the system. Because of this, applications developed in this manner often miss key user requirements. Consequently, database developers have become more and more clever about building extremely flexible databases so that should the user requirements “change” the database can be changed quickly to accomodate them.

This has been cited as the next generation of programming language. Microsoft Access follows this model, where tables and relationships are created in the database and these tables are then “bound” to forms on the user interface.

Model driven development (middle-out)

In this method, expert modellers design the system using a modelling language. The code, database (and sometimes even the user interface) can then be generated from the model. Ideally, the model driven approach would do away with the need for programmers because everything is generated. Model driven development works well with Naked Objects which is a very poor form of user interface design (albeit very flexible).

If this sounds suspicious to you that’s because it is it is. I believe that Model driven development is flawed in that it still relies on Freegan representations of the business “objects”. This makes it inaccessible to any but trained software analysts or developers, simply out of reach of the end user.

Model driven development has also often been cited as the next generation of development language. The idea being that the model is the purest, least changing representation of the system and everything should be dependant upon the model. An example of this is BoldSoft’s “Bold” components. Which allow the developer to model the system, then generate the business objects, database and user interface all from the same model.

Interface driven development (top-down)

I would like to introduce this method which I think has been a little over-looked over the years. One example of this is “programming by demonstration” where the user interacts with the user interface to create an application.

I think it has been overlooked because the user interface is often considered too volatile and determined far too much by the whimsy of the end user to be considered the starting point for serious application development. However, I believe that by starting at the user interface we can avoid the pitfalls of the previous two development methods and actually “model” the user’s requirements in as pure a form as possible: the user’s conception of their problem domain, the user interface.

Hybrid (outside-in)

I discussed the above three options with Kelly Smoot, who is a professional software architect. She drew my attention to another option. This option involves starting at both the database and user interface side of the spectrum and working inwards towards the business objects.

This means you can design a normative, normalised database and can generate a nice robust and scalable data access layer. It also means you can design the most usable interface possible. The challenge then becomes marrying these two in the business objects.

There are two risks here

1. The database and user interface are written for different purposes and they are impossible to put together in any meaningful way. This risk can be mitigated by doing the user interface design up front, then deriving the database requirements from the user interface.

2. The business objects become so complex as to make implementation very difficult to debug and extend. This risk can be mitigated somewhat with unit testing.

I am beginning to settle on this last option as a pragmatic approach to software development.