« Enterprise-scale Fault And Issue Management | Main | BPM and bugs »

Abraham Maslow, creator of the hierarchy of human needs, famously said: "If the only tool you have is a hammer, you tend to see every problem as a nail." But what if you have a Swiss Army Knife?

This is the 12th and final article in my blog series on The Future of Programming. The series started back in March, and has addressed various topics including:

• Dealing with acronym hell


• BPM without a BPMS


• Managing outsourced application development


• Professional development for developers


• Quality planning


• Managing change in large-scale development

In this concluding article, I will discuss a theme that underlies all these topics.

When I entered the IT industry, I was trained to become not just a software developer, but a software engineer. What is the difference?

Engineering is fundamentally about techniques and tools. An engineering job consists essentially of assessing the situation, deciding what techniques and tools are suitable, then applying them. Hence, in order to be an engineer, you need not only depth of knowledge, but also breadth - a wide-ranging understanding of problem types and solution types.

I began my IT career in the late 1980s. At this time, object-oriented programming was just getting started. Some would say that it is still is! However, there were certainly fewer mainstream programming languages back then, fewer (and less powerful) development tools, and far fewer programmers. Also there were hardly any packaged applications for business use. As a result, it took a lot longer and cost a lot more to introduce new software into an organization.

As a result, it was more common for large-scale software projects to be conducted on quite a formal basis. Not only was the choice of tools and techniques more limited, making it easier to apply an engineering approach to software development, but also the stakes were higher. Despite this, many projects failed, of course, but at least there was recognition - fueled by the writings of thinkers such as Fred Brooks - that software development needed very careful handling if it was to succeed.

Now, in today's world, we have a plethora of new development tools - including BPM suites claiming to make it possible for business users to build their own enterprise software, and SOA suites claiming to make it possible for an organization of any size to share bits and pieces of code willy-nilly. As a result, many organizations are dispensing with the costly and time-consuming engineering processes, in favour of what appear to be the latest and greatest quick-fix solutions.

Well, why not, you may ask? I have 2 main fears about current development trends.

First, organizations seem to be confusing tactical and strategic solutions. A set of BPMN flowcharts may speed up your logistics process, or shave 1% from your invoicing costs. But this is no substitute for an organizational model, a model that is based on high-level business goals. It is easy to adopt short term point solutions that in the medium term fragment your enterprise IT architecture, and in the long term render it unmanageable. In particular, the true problems of SOA Governance are only just starting to emerge. BPM and SOA may in fact be driving a return to the integration nightmare that they promise to solve.

Second, whatever happened to testing? I recently heard a BPM Suite vendor speak proudly of a BPMN process they had implemented that contained 250,000 steps. This represents a vastly complicated piece of business software, so I asked how they had tested it. He replied that testing was unnecessary since their tools did not require the user to write lines of code (just to draw diagrams), and anyway their products contained simulation features if you really wanted to prove that an application worked as expected. He then went on to say how this approach must be OK, since other organizations are using their suite to build safety-critical applications.

This response made me blanch, and still sends shivers down my spine. What sort of world is being constructed using such tools? Whether created via diagrams or as text, software needs testing - and simulation is no replacement for structured, automated, exhaustive, regressive verification. Further, anyone who knows anything about the theory and practice of simulation will recognize immediately that simulation of a flowchart of 250,000 steps is itself a hugely complex and risky exercise.

TAKE AWAY

No matter what tools you use, it is highly dangerous to take the engineering out of software development - yet this is exactly what is happening with the emergence of new BPM and SOA tools.

If you are responsible for software development, I suggest you ask yourself a simple question. Do I care what happens 12 months down the line?

If not, then you can probably ignore much of what I have written in this series.

Otherwise, I suggest you stop and take stock. Remember that much of what you read online and in magazines is written by people with a vested interest in getting you to adopt certain new commercial products. It takes only common sense to see that the practice of software development is nothing more and nothing less than engineering - and engineers in other fields are very cautious indeed about using new techniques and tools to build big things. Why should software be any different?

Posted by keithhb in Business Process Management • Management • Service-Orientated Architecture |Digg This|Add to del.icio.us