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

In response a previous blog entry, Gerald Loeffler raised a question about the potential relationship of Naked Objects to workflow or business process management (BPM).

I have always disliked both of those concepts for three reasons. The first is from technical perspective: they tend to encourage the separation of procedure from data and thus discourage good object-oriented design. The second is from a human perspectice: workflow and BPM systems tend to encourage a management philosophy that disempowers the users. I wrote about this in the original Naked Objects book back in 2002 and subsequently in my thesis.The third reason is that workflow, as generally conceived, simply doesn’t work! Recently I met with a workflow expert who works for one of the major systems integrators; to my susprise and delight he concurred with my assessment. He told me that in a very high proportion of systems that they install, the workflow element is completely switched off within a few months of the system going live. I asked him why his company continued to build workflow into new systems and he told me that it was invariably because the client’s management insisted upon it.What I mean by ’as generally conceived’ is building explicit representations of complex business processes or flows of work, and then running these scripts on some kind of engine that drives the tasks that individual users perform. This idea appeals hugely to management for two reasons: it allows the script to easily edited as the business organisation changes; and it gives the management better control and information about what is going on. In theory, that is. In practice this breaks down because real business processes are seldom capable of being 100% scripted, and as soon as you allow any kind of non-scripted variants the whole system breaks down. In The Social Life of Information (an excellent book), John Seeley Brown points out that the most valuable people in an organisation are those who’ve worked out how to get the job done for the customer, by overcoming the constraints of the formal business processes.However, I believe that there is a legitimate role for work assignment. Indeed I have designed several Naked Objects applications that involve a Task object. When the user logs on, they are presented with a ‘work list’ or ‘task list’. Each Task typically has a TaskType, a longer description and/or instructions, and, optionally, a Task Subject - the domain object (such as a Customer or Order), if one exists, that would be the starting point for the user to perform the task. Tasks may be assigned to an individual user or a team, and they may be transferred from one user or team to another. When the user has completed the task, they invoke the ‘Completed’ action on that Task, which records the date/time of completion, possibly one or more ‘completion options’ to record how it was completed, and then removes the Task from the worklist.