Devil's Advocate: Software never changes

So with developers and teams coming and going all the time, what can be improved?

Is a project-based approach to the bulk of software development resulting in teams repeatedly inventing the wheel? Martin Brampton wishes the academics would do more to help out… We are now told that service oriented architecture (SOA) is an important new way to develop software. Claims like this crop up regularly. What is curious is the lack of any historical context or continuity with earlier techniques. In fact, most of the ideas in software are much older than is usually admitted. I recently noted that new recruits to the IT business are increasingly expected to have followed a relevant university course. Yet academics play strikingly little part in the development of ideas for software development. And it is hard to think of any other science-related discipline that so consistently ignores its own past achievements. Surely we would make more progress if we encouraged rigorous scrutiny of software ideas and took more trouble over placing them in an historical context? Perhaps commercial pressures are driving people to make claims for new ideas. But in reality, there is very little that is genuinely new in software. Most of the good ideas have been around for decades. One thing SOA is about is segmenting programs into units. Well, the notion of a procedure or subroutine must be about half a century old by now. It came to prominence along with the very earliest high level languages. A clean example of these was Algol-60, which had a good set of computational abstractions and was defined in a wholly machine-independent fashion. Freedom to use meaningful words as identifiers encouraged people to write programs in terms that related to the problem domain. It's what is now referred to as closely supporting business processes. High level languages also encouraged the writing of standard subroutines that could be reused. This approach worked very well for well-defined problems. It became increasingly possible to rely on a library of reliable and efficient mathematical routines. But a standard routine to handle a business problem is not merely a technical issue that can be solved by some new jargon and a lot of enthusiasm. Using names in programs that referred to the problem domain was helpful but also turned out to be tricky. An obvious move was to build a catalogue of terms so that the same name could be used in every program in the same way. Unfortunately it was soon discovered that the same name had to be used in a variety of contexts that were subtly different. The software behaviour consequently depended on the context. Now another discipline, also evolved some decades ago, was the building of software models. In these, software was used to represent the objects of the problem and to give the objects behaviour. That could be adapted to commercial problems through the design of business-related objects. SOA is couched in terms that are highly reminiscent of objects. It refers to XML, which is readily described as data objects without behaviour. It advertises reuse, one of the claims of object oriented programming. Of course, it is linked to web services, a topic that makes it trendy and modern. Yet all the techniques that lie behind it are apparently ignored, preventing us from building effectively on the experience gained in the past. We know, for example, that one of the biggest obstacles to reuse is nothing to do with software technology. It is the project orientation of many organisations. If software is developed and financed within defined business units, there is no incentive to invest extra effort to create objects with organisation-wide application. Certainly it is good to have fresh ideas or to find new ways of applying old techniques. But would not more be achieved if we took advantage of the greater role of academic study in IT? We could concentrate on a better understanding of techniques that pay dividends in real situations, instead of repeatedly claiming to have invented the wheel. ** Martin Brampton is a director and founder of Black Sheep Research (www.black-sheep-research.co.uk ), an independent consultancy providing research, writing and speaking services on a wide range of business and technology subjects. Martin was previously a director at Bloor Research, and has worked with IT as a user and analyst for over 20 years. He can be contacted at silicon@black-sheep-research.co.uk. Or contact us at editorial@silicon.com. For past Devil's Advocate columns see the links below, or type 'Devil' into our search engine.