Model-Based Development: A Historical Perspective
This chapter is from the book
This chapter is from the book
This chapter is from the book
- Problems are the price of progress.
- —Charles F. Kettering
Compared to the physical sciences and the Industrial Revolution, software development is relatively new on the scene of human progress. It took more than a millennia for the physical sciences to play a ubiquitous role in modern life and it took the Industrial Revolution over a century to play a similar role. Yet computers and software have become an invasive and essential part of our lives in three decades. Alas, the road traveled has been a bit rocky.
This chapter provides historical context for why the OO paradigm was developed. To fully understand and appreciate the paradigm we need to understand what problems it sought to solve, so we start with a bit of history. We will then examine some weaknesses of the paradigm that dominated software development immediately before the OO paradigm appeared. Finally, we will provide a technical context for the rest of the book by examining some of the important technical advances made prior to the OO paradigm that were incorporated in it.
History
Essentially there was no systematic development at all through the 1950s. This was the Dark Ages of programming. It is difficult for today's developers to even imagine the conditions under which software was developed in those days. A mainframe had a few kilobytes of memory and paper tape was a high-tech input system. Western Union had an effective monopoly on teletype input devices that required several foot-pounds of energy for each key press—it was the machine that crippled programmers with carpal tunnel syndrome before the medical profession had a name for it. There were no browsers, debuggers, or CRT terminals.1 Basic Assembly Language (BAL) was the silver bullet to solve the software crisis!
In the late '50s and early '60s better tools began to appear in the form of higher-level computer languages that abstracted 1s and 0s into symbolic names, higher-level operations, block structures, and abstract structures such as records and arrays. It was clear that they made life easier and developers were far more productive, but there were no guidelines for how to use them properly. So this renaissance gave birth to the Hacker Era where individual productivity ruled.
The Hacker Era extended from the early '60s to the mid '70s. Very bright people churning out enormous volumes of code characterized this period—100 KLOC/yr. of FORTRAN was not unusual. They had to be bright because they spent a lot of time debugging, and they had to be very good at it to get the code out the door that fast. They often developed ingenious solutions to problems.2 In the '60s the term hacker was complimentary. It described a person who could generate a lot of code to do wonderful things and who could keep it running.
By the late '70s, though, the honeymoon was over and hacker became a pejorative.3 This was because the hackers were moving on to new projects while leaving their code behind for others to maintain. As time passed more special cases were exercised and it was discovered that the code didn't always work. And the world was changing, so those programs had to be enhanced. All too often it became easier to rewrite the program than to fix it. This was when it became clear that there was something wrong with all that code. The word maintainable became established in the industry literature, and unmaintainable code became hacker code.
The solution in the late '60s was a more systematic approach that coalesced various hard-won lessons into methodologies to construct software. At the same time, programs were becoming larger and the idea that they had a structure to be designed appeared. Thus software design became a separate activity from software programming. The methodologies that began to appear during the twilight of the Hacker Era had a synergy whereby the various lessons learned played together so that the whole was greater than the sum of the parts. Those methodologies were all under the general umbrella of Structured Development (SD).4
The period starting around 1980 was one of mind-boggling advances in almost every corner of the software industry. The OO paradigm5—more specifically a disciplined approach to analysis and design—was just one of a blizzard of innovations.