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 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 managing those who do. 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 rearing its head over and over again: reusing battle-tested software is preferable to writing new software. How can we do a better job of reusing legacy software?
Reusability: The Holy Grail
The 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:
- Projects created primarily from reused software experience only about a third of the defect density of those that are new.
- Projects created primarily from reused software take about a quarter of the time and resources of those that are new.
There are many other nuggets. It's a great book.
Wires
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.
In addition to the insect problem, reusability of this kind of software left much to be desired, as you might imagine.
Binary
Later, binary, octal and hex programming appeared and, after that, assembly language. 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 quite literally, in some cases. I've seen people tape or glue pieces of paper punch tape together to make a complete program from parts.
Spaghetti Languages
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 method 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.
Structured Programming
And then structured programming was born. Pascal, Modula 2 and related languages influenced Basic, Fortran and others to allow for libraries of parameterized functions that could be reused. Memory management, string manipulation and device access were common targets of code reuse. Structured programming allows for code reuse quite well, and it is still in wide use today.
Objects
It was limited, however. Higher levels of abstraction and reuse were sometimes hard to achieve, especially on very large software projects. And so, object-oriented programming (OOP) with the concept of inheritance was born. It was going to save us all. Great books like "Design Patterns" showed us how. And, in fact, it does help. Some languages are great for it, like Python. Some can push you toward suicide, like C++. Yet there are places where OOP isn't helping much. One indisputable place where OOP by itself is useless is in working with ancient code that isn't OOP.
We want more ability to reuse more of the software that has been out there working for years.
Ultimately, the idea behind SOA is to do for Web services what MyYahoo did for static data. SOA should allow you to build dashboards of active Web services components and create applications on the fly that behave your way - the way you want them to behave.
Open your minds (and your wallets) - here comes the next big thing.
Enter SOA - the next wave of reusability.
Run your Legacy IT Shop Like a Startup
Whenever "the next big thing" is announced, CIOs are understandably skeptical. At a recent IBM SOA conference that I attended in Dallas, one CIO of a Fortune 500 firm said to me, "Is there really a standard here or is this like the OSF where all the Unix vendors bickered endlessly, producing little agreement while Microsoft chortled in the background? SAP says they have thousands of companies participating, IBM says they have 300 ISVs and thousands of assets- are they counting the same things? Are they in agreement over definitions? I don't think so."
