Evolution of Software Engineering Paradigms

By J. W. Rider

J. W. Rider Consulting

http://www.jwrider.com/

November 2004

An old saw states that “paradigms are worth about twenty cents, including inflation.” Unfortunately, it seems one of the lessons we must learn anew with continual generations of computer programmers.

Every new software engineering paradigm that gets invented seems to be greeted with the battle-cry “Revolution!” as if everywhere software engineers and programmers were freed suddenly of all the evils that the previous paradigm had foisted upon them. Each new generation of unspoiled programming acolytes is admonished to go out into the world, to spread the word, and to suffer not the sins of the previous generation.

It’s hyperbole of a most insidious nature. Not one of the paradigms ever did a single thing in a revolutionary manner. None ever overturned the important issues from earlier paradigms. Never. Nada. Nyet. Nullo. No way, Joe. Negatory, good buddy. It is only through the myopic viewpoint of the newly initiated that the only programming paradigm they have ever known reaches such a blessed stature it surely must have wrestled previous and less fit paradigms to an early and ignominious extinction worthy of all such dinosaurs.

The truth is that each and every one of these so-called revolutions was built unequivocally on the features of the paradigm that was its predecessor. Software engineering paradigms did not revolt; they evolved! None of the lessons learned was ever forgotten. In many cases, the only things that were changed were those features that had been left completely neglected by an earlier paradigm.

In some respects, that explains why we have progressive shifts anyhow. At the end of any one paradigm phase, it may seem that everyone knows everything needed to write complete, consistent, and clear code. However, some programmers (the “masters”) still manage to write more code than all the rest of the programmers put together. Obviously, the master programmers have some additional insight into the software engineering process. Of course, you’d never be able to get the secret from them. It would be like trying to pull requirements out of users, and master programmers often don’t have any clue as to why they do it that way. They just do it that way.

So, we are completely at the mercy of …. researchers. Those are the people who can watch what it is that master programmers do differently from other programmers and put a catchy name onto it. Of course, there are many researchers (more than there are master programmers), and some of the researchers are better than others. Their keen observation and insightful analysis is vital in order to tell us how to write the software in the future.

It didn’t happen overnight. It took many lines of code, many master programmers, and scores of researchers for us to be able to look back at what we can see as the mainstay of computer programming paradigms.

Paradigm	Common Features
Machine “Problems can be solved by running a program in a computer.”	Demonstrates feasibility of representation of problem solutions within computers. · Machine Instructions (“Op codes”) · Data representations · Input · Output
Mnemonic (or Symbolic) “Programs should be written in a manner that makes them easily understood by human beings.”	Improves readability of computer programs by using commands that looked words and numbers that looked like numbers. · Variable declarations · Assignment statements · Global scope of identifiers · Absolute, conditional jumps · Statement labels · GOTO statements · Comments
Modular “Large programs should be composed of smaller blocks of code.”	Simplify understandability of programs by partitioning of large problems into smaller problems that are more easily solved. · Subroutines, functions, procedures · Return statement · Formal/actual arguments · Separation of code/data · Local Scope of identifiers · Function libraries
Structured “Proper programs should be coded in a way that minimizes the number of detours from the main flow of the program.”	Improve readability of programs by limiting the number of arbitrary ways in which statements can be put together. · Sequence · Blocks · Block scope of identifiers · Selection · If/Else statements · Case/Switch statements · Iteration · Do/For/While/Until statements · Recursion · Exception handling · Throw/Raise statements · Catch statements · Controlled jumps · Break/Continue/Cycle statements
Object-oriented “Programs should be written as a collection of otherwise independent objects that interact with one another.”	Simplifies programs by placing logically related parts close together and by having similar parts of the program behave in a similar manner. · Encapsulation · Classes and objects · Fields/Attributes · Methods · Inheritance · Constructors and Factories · Polymorphism · Interfaces/abstractions/pure
Event-driven “Programs should be written as responders to external and internal stimuli.”	Makes programs more understandable by implementing common frameworks and conventions followed by all programmers. · Events · Event generators · Event handlers
Visual “Programs should be written by focusing on the interfaces first and adding details later.”	Facilitates communication between programmers and users by using standard and expected user-oriented components. · Visual components/containers · Properties · Events

So, what’s going to come next? What’s the next great programming paradigm going to be? What will make the next programmers look over the products of their elder siblings and remark, “Visual programming. How antiquated!”? We have no idea. We never did.

There are hundreds of candidates for techniques for improving code-writing with every stage. All of them make some sense or another. However, identifying which one is going to gain the wide-spread acceptance in the long haul takes a prophet, not a programmer. The best I can do is to pull out my buzzword generator and see what is being bandied about:

Distributed programming, data-base programming, client/server programming, intelligent programming, multi-threaded programming, safe programming, security programming, robust programming, functional programming, ego-less programming, extreme programming.

Your guess is a good as mine. Take your best shot.