Naked Objects

I have argued for some while that it is possible to divide business systems development projects into two distinct categories: ‘requirements-dominated projects’ and ‘engineering-dominated projects’.  One way to understand which of the two types you are dealing with, is to try to imagine that project failing, and then to write down a list of the 5 most likely reasons why that particular project had failed.  If that list looks something like:

• The customers didn’t really know what they wanted
• We misunderstood the requirements
• By the time the system is delivered the requirements had changed
• We did what we were asked but the customer didn’t like the result
• The users said the system was unusable

then you are dealing with a requirements-dominated project.  If, on the other hand, your list looks something like this: 

• Response times were too slow
• The system did not meet the targets for reliability / availability
• The system was not secure enough
• There was a problem procuring certain components
• The system didn’t work in the intended environment

then you are looking at an engineering-dominated project.  Of course any business system development project could fail for any of those reasons, which is why I stressed the need to consider  the ‘most likely’ risks for a particular project.  In today’s world, any system that has inadequate security, or reliability, or performance, is going to be a failure, but for many types of business system, addressing those issues is now comparatively straightforward.  Conversely, any type of system that has an unusable user interface will be a failure:  but if your business system has only simple functionality then it’s a straightforward matter to mitigate this risk. The ‘so-what’ from this two-fold characterisation is that requirements-dominated projects are the ones that demand agile development. Engineering-dominated projects don’t: in fact they’re better off run using conventional ‘waterfall’ methodologies.  Don’t get me wrong: there isn’t a software project on the planet that couldn’t benefit from at least one of the practices being promulgated under the banner of agile development.  But many of those practices are just the embodiment of modern common sense. 

I am talking about the core, definitional, practices within agile development:  highly-iterative development, small releases, continuous capture and prioritisation of requirements, intense customer involvement.  These practices are the only way you can succeed in the development of any requirements-dominated project.  Attempting to work in the old-fashioned way of trying to lock-down a specification up front is doomed to failure.  Conversely, though, creating a tight specification up-front is precisely what you should do for an engineering-dominated project.

Needless to say, I think, Naked Objects has the most to contribute to requirements-dominated projects.

Richard