vnunet.com comment: Clive Longbottom on functional development for non-coders

Clive Longbottom, service director at Quocirca

As the age of the application enters its twilight hours, the new clarion call is for the provision of services that facilitate changing business processes.

Existing application vendors, such as Oracle and SAP, are scrambling to provide solutions built around service oriented architectures and web services, and niche vendors are touting their solutions as callable service functions for these environments.

And yet we still see hordes of code developers working away like medieval monks, crafting bespoke code that will give their masters that extra differentiation in the market to guarantee survival.

The problems with bespoke coding are well known and, in more cases than not, end up costing an organisation more than the benefits gained.

For example, code is rarely fully documented and new coders struggle to understand how the original coder put together some of the more clever (or, more often, just overly complex) parts of the code.

Bespoke code also tends to be less flexible; as organisations are increasingly driven by changes in market conditions, code needs to be able to respond to these forces. The trouble is that re-coding takes time, and retro-testing becomes a major problem.

A further problem is that many coders are one step removed (at least) from the business. Yes, they are great at their jobs, but the level of understanding of the actual business needs can be, let us say, loose.

The initial discussion takes place between the line of business representative and the IT department, a user specification document is agreed, and off goes the coder to create a first pass version.

This may take a while, and when it is put in front of the business person, the response is often more along the lines of 'It will do' rather than 'Wow, jus t what we wanted.'

Modern coding tools, such as Eclipse-based solutions and Visual Studio, do try to help with built-in or third-party tools to provide software code management, collaborative tools and so on.

But the fact remains that the speed of result, the quality of the code and the overall resulting functionality tends to be down to the coder, and that person may leave not long after their major work hits the business.