8th April, 2003 
Methodology, not theology

Don't get me wrong. I don't mind methodologies in so far as they give you a framework for thinking. The framework gives you a general structure to hang your thoughts on. It is a tool to be used in the software development process. It should prompt a designer to consider important areas of the design process but a framework should never make the decisions.

The ISO 9000-3 framework was intended as a skeleton for approaching the problems in the development, supply and maintenance of software. It provides a checklist of procedures, plans, records, documents, audits and reviews.

There has been adoption of such processes as a set of regulations for development. It becomes a codification of the design processes, an assembly line for software development - such that any practitioner, however unskilled, may follow the instructions and then deliver a product that meets the requirements. The methodology decides the course of action and for it to do this task requires a bulky set of prescriptions to deal with every situation. It is either that or the avenues of development are severely restricted.

As an interested observer of design practices, I had the fortune to encounter the latter problem in the workplace. A particular design situation required the use of Petri nets. Unfortunately, the quality management system only allowed for design expression in the form of data flow diagrams. No amount of explaining would sway the quality management team from the written word of the quality management system. I drew a DFD to satisfy the quality processes - even though it did not focus attention on the synchronisation issues that were the important consideration.

The object-oriented methodology has also been the vogue. It has been touted as the way to achieve fewer defects as it ties the use of the data to the data form. There is a rigid data structure and a binding contract for the employment of that structure in the object-oriented model of the world. It has solidity and inflexibility, and is one step removed from implementation. These are useful traits in certain situations. There are other situations where this may not aid and may even hinder the understanding of the system's interaction with the real world. The detail and focus of the object-oriented view can draw the designer's attention from the wider system implications and obscure the natural organisation of the system.

I still use DeMarco's context diagram as the starting point for functional decomposition and as I move through the decomposition, I begin trying design patterns before looking at the specifics of the object model. List the salient features of the system, recognise the salient features that your methodology identifies, and switch methodologies and models as necessary to complete checks of all features in your list.

Know the benefits and the shortcomings of the methodologies that you use. Understand the forces and the environment present for each step in your development situation and choose the appropriate methodology or the appropriate parts of the methodology. Lastly, let the designers make the design decisions and allow the methodologies to remain the servant of development.