|
By Curt Finch
Service-Oriented Architecture (SOA) is a style of information systems architecture that enables the creation of applications that are built by combining loosely-coupled and interoperable services. These services inter-operate based on a contract that is independent of the underlying platform and programming language - Wikipedia
I’ve been writing software for a long time.
When I was 14, I got an HP programmable calculator that I taught to tell time by flashing hours, minutes and seconds repeatedly. It used a loop of null operations to take up the time between each second. Slight changes in room temperature would cause it to speed up or slow down the rate at which it performed these loops, ultimately making it a poor timepiece.
But I was hooked – I have always loved programming since those days.
That was almost three decades ago and since then, I've been writing some kind of software almost every day or managed those who did. For the last decade, I’ve been running a company that creates and sells software.
In all that time, there has been a recurring theme in our industry that keeps asserting its head over and over again: reusing already battle-tested software is preferable to writing new software. How can we do a better job of reusing legacy software?
Reusability – The Holy Grail
That same wonderful HP company that got me started on this path (and is now one of my customers) put out a great book in 1992 with the obtuse title, Practical Software Metrics for Project Management and Process Improvement. I know it sounds like a snoozer, but it’s not. Although this book is more than 14 years old, it could have been written this year because the concepts are still relevant. Among the research are these two nuggets of wisdom:
1. Projects created primarily from reused software experience only about one-third the defect density of those that are new.
2. Projects created primarily from reused software take about one-fourth the time and resources of those that are new.
There are many other nuggets. It's a great book.
Wires, Binaries and Spaghetti
The first computers were programmed by electrical engineers moving jumper cables around in the back of a giant mainframe. This is how the concept of a 'bug' in software got started. A bug crawled into some of these wires, shorted a couple of them, and changed the logic of a program. (http://www.jamesshuggins.com/h/tek1/first_computer_bug.htm)
In addition to the insect problem, reusability of this kind of software left much to be desired, as you might imagine.
Later, binary, octal and hex programming and, after that, assembly language, appeared. These were huge improvements over moving wires around. Copying and pasting text was the best that you could do here if you wanted to reuse code. When I say ‘copying and pasting,’ I mean this, in some cases, quite literally. I've seen people tape or glue pieces of paper punch tape together to make a complete program from parts.
The first language I ran across once I moved beyond programmable HP calculators was Basic. Like COBOL, Basic didn't initially have subroutines or parameterized functions, which led to hideous gobs of icky spaghetti code. Copying and pasting - thankfully in some sort of text editor so no glue was required - was the most common way of code reuse here. But languages such as Basic and COBOL, though primitive by today’s standards, had the enormous advantage of allowing for code reuse on different chip architectures, which you couldn’t do with assembly or binary.
|
