Sunday 23 March 2008

Limitations and Constraints of Translational Development

The previous notes I have drafted have outlined on the differences between translational and elaborational approaches to system development. There are several costs incurred in adopting a translational approach, and these are summarised here.

The whole approach of translational development is intended to deal with large scale, complex projects. It can therefore be seen as overkill for smaller projects, or for small team projects. I trust that my development of the project I am using as a test bed will show that it can be successfully, and efficiently used for a single man project.

The approach is somewhat prescriptive, and requires discipline in the development process. There are certain criteria which must be met in the development artifacts, or the method will not be successful.

There is a substantial problem of "where do I start". If the method prescribes modelling the application, and modelling the architecture and then applying the latter to the former in order to provide the final system, how do you start this process off? My test bed project will illustrate how to break into this (apparently incestuous) cycle of modelling and system generation. However, unless one starts off with a pre-populated architecture, there is undoubtedly a large amount of technical work to be done up front, which appears not to be productive, in that there is no tangible system as a result of it. The approach is productive, but initially does not appear so.

Tied in with the difficulty in starting the project, there is no doubt that the initial iteration, if an iterative approach is adopted, will be much larger than subsequent iterations, and does not tie in well with the lessons learned from extreme programming.

In order to develop a system iteratively, using the translational approach, one has to develop a vertical slice of both the application and the architecture. This may mean that analysts, and software architects may well have to be developing in multiple disparate domains which can lead to "jack of all trades" syndrome - where everything is done, but not necessarily very well. This will impact on the subsequent development, and may result in rework that would not otherwise be necessary.

This note concludes my overview of what I have described as an alternative approach to system development, from that normally adopted. These notes will go on to describe this alternative approach in detail, and illustrate it by reference to the software development I am using as a test bed, and exemplar for the method.