Number 218 - July 2001

The Pursuit of Elegance
By Virtual Jack, dacs.doc electric: Random Vectors: Danbury Area Computer Society, February 2001
The pursuit of excellence. A virtue admired by all, but practiced by few. But if everyone admires it, why doesn't everyone dedicate his or her time and effort to it? There are reasons and excuses: no time, pressure to get the job done, necessity of just making money any which way, and so on, and on. The pursuit of excellence is actually a luxury requiring both the right circumstances and the opportunity.     And so is revealed one of the great advantages of being a computer programmer. Writing computer code requires excellence, else it just doesn't work. The managers and administrators understand this, so computer programmers are given both the time and opportunity to constantly improve their mastery of their craft. Managers and administrators who do not recognize this are soon found responsible for project disasters and quickly relocated by their managers.     Succeeding as a computer programmer requires constant adapting to machine capability and new operating systems. Every piece of software written is to do something new and different. Often it is to do something that has never been done before. True, there is a great deal of code written to fix bugs and modify existing programs, but even that requires all the skill and knowledge required to write original stuff.     Writing computer code requires the fine touch that any master craftsman develops over years of practice. And it has the additional challenge that the craft itself is constantly changing. It also requires the mental skills to interpret and translate program requirements written in human terms and intentions. The programmer has to convert the words and diagrams to the functional capabilities of the computer machine.     The computer programmer is the link between the user and the machine. He or she must relate and bond to both. It is a most marvelous role to be in. And it is a most marvelous line of work to be in.     The hazards of the job actually come more from the machine side than they do from the user. There is a definite temptation to favor the machine more than the user/manager. The user/manager can complain and make the human side of your life miserable. The machine, never. The machine rewards you when your code works by performing magnificence. When your code is not working, the machine just doesn't do anything or doesn't do it right, but it's never anything personal.     So there is a definite temptation to indulge the elegance side of programming over the mundane, practical consideration of program maintenance, clarity and readability.     Consider an example that first appeared in a Byte Magazine article many years ago can illustrate this. The system requirements are that a program variable is an integer, which always has a value of either 1 or 2. The program requirement is to flip that value. If it is a 1, make it a 2. If it is a 2, make it a 1.     Now there are many ways to code this operation. Most are straightforward and practical. But there is also an elegant way that is faster, shorter, and much more pleasing to the ego than the others.	(Suggestion to the Reader. Take a moment to work out this "elegant" solution before reading on.)     The straightforward solution is some variation of        if (I=1) then I=2;        if (I=2) then I=1:     What this is saying is that the variable is in the memory location whose address is represented by I. Go to that location and test the contents of that location. If it is the integer 1, then replace that content with the integer 2. Repeat the process in the next statement testing for the other value. Of course, if the above were two sequential lines of code, the value would never be 2 and the obvious bug would show up eventually.     So we then would write something like        if (I=1) then I=2 else I=1     That would work. Or we could go back to our version with the bug and correct it by writing        if (I=1) then I=2;        Go to 100;        if (I=2) then I=1;        100 continue     But, of course, here we use four lines of code to do what we could do in one line. And the four lines look pretty simplistic and dumb. We certainly wouldn't want to do that.     OK, now what about our elegant solution, which I am sure you have all worked out. We simply write        I=3-I     Beautiful. We don't even bother testing. We take the integer value of 3, subtract whatever the contents at I are, and put the result right back into I. Neat. Cool. Programmers love to do that sort of stuff.     Unfortunately, while elegance may be a halo, the world actually runs on practicality. Our elegant solution is the stuff that bugs are made from. While it would work perfectly in Version 1.0, down the line there will be problems. There will be new features, new hardware, and new versions. The original programmers will be long gone. Something else will change. Perhaps the assumption that the value of the variable will always be a 1 or a 2 will change. Perhaps a maintenance programmer will be looking for a conditional test in the thousands of line of code, perhaps, perhaps, perhaps...     So as reluctant as we programmers may be to admit it, we have to acknowledge that our klutzy four liner is probably the better choice. The execution time and the few extra bytes of machine instruction are negligible in today's machines. The code structure allows safer modification. It is obvious what the code is doing.     So our satisfaction must come from knowing that we could have done it the elegant way. In a transient moment of noblesse oblige we make it easy for the maintenance programmer in the years to come. When we finally see all that code working and doing what we wanted it to do, everything feels great and worth it all. And our bond to the machine grows ever stronger.     Virtual_Jack is an old, retired computer programmer who never wants to lose that bond.
Number 218 - July 2001