Computer Science or Software Engineering - An Elemental Problem

What is the difference between Computer Science and Software Engineering?  That depends on the nature of the problem you are trying to solve -  is your problem one of Silicon or one of Carbon?

In my 20-year career in working with software, the single biggest issue has also been an elephant in the room: the abysmal success rate of large software systems.  Plenty of books have been written on the subject with lots of great, if unheeded, advice.  Scope creep, ambiguous or missing requirements, poor communications, bad risk management; lots of reasons have been documented and just as many if not more solutions have been suggested.  Brooks gave us "The Mythical Man-Month", Yourdon writes of "The Death March", Tom DeMarco has "Peopleware". All of them attempting to answer the question, "Why is it so hard to write software?"

If you take the all the books on writing software and put their suggestions in one big list, the first question would be, "If we have all the answers, why don't we use them?"  That might be nice for getting it off your chest but isn't has helpful in pointing us in the right direction. At its core, this question does have a useful kernel, it assumes that 'we' are the problem.  If only we used this process, if only we implemented that practice, if only we hired the right people, if only we kept our teams motivated.  As an aside, most of the reasons for failure are management reasons, not technical ones.  It should be no surprise that many find the case study on the sinking of the Vasa in 1628 to be very instructive. The blame is as much, if not more so, on the King's unrealistic demands as on the builder's efforts to failure to meet the royal requirements. In our endless efforts to build bigger, more complex and complicated software solutions in the face of almost certain failure, should question our sanity; one definition of insanity being, "doing the same thing and expecting different results." Biting off more than we can chew, choking, and then doing it all again time after time only shows how our hubris can get the better of us, allowing us to continue on our Sisyphean task.

This brings me to an interesting observation.  There is a long running debate over whether computer programming is/should be considered a form of artistic expression or of engineering prowess.  Computers have such a wide scope that many sub-fields have crept up, hardware and software being the most obvious. Hardware is typically the realm of the engineer, designing circuit boards or embedded sensors.  This changes as the hardware gets larger in size or scope.  CPUs have microcode, missiles have on-board navigation systems with programmable targets.

Most universities that offer degrees related to programming computers name the department Computer Science.  Now, being considered a 'science' may be just a way of expressing the notion that computers are deterministic and worthy of comparison with mathematics or engineering, having likely grown as an offshoot of the field of electrical engineering.  Whether it be data mining, security, networking, or pure algorithms, most of the areas seem to ignore the question of why software is so hard. They assume the problem is in the silicon computer chips.  Curiously, these fields don't even attempt to address this most difficult of questions, assuming improvements of our silicon constructs or their usage will somehow mitigate our human foibles. If only we had better tools, or faster computers, etc. then our carbon-based brains could somehow ascend above the project management miasma and become a beacon to those who struggle and toil without end. Considering the gargantuan number of man-hours and humongous amounts of money wasted, such an accomplishment would be of heroic proportions, mythic even; a modern-day retelling of Prometheus or Sisyphus.

The truth is that Computer Science may bring improvements in areas where the problem is in the silicon, it is mute when asked to provide answers to problems of a carbon nature.  Software Engineering attempts to develop solutions that include how humans work together.  Software Engineering does not assume that software development is as cut-and-dried as putting the right circuits on a board to achieve the desire product, or breaking down a complex problem into constituent algorithms to make the problem more manageable. There is no magic bullet, no single development process, no single answer.  To understand why humans have a hard time developing software, we must admit that humans are part of the equation. Doing is brings with it a cold truth about humans - they are non-deterministic by nature.  Alistair Cockburn describes it as people being non-linear, first order components in software development.   To answer the question of what is software development, we might have to take detours through Psychology, and may be surprised to end up working with Philosophy even.

What I learned about Cryptography

In preparing a presentation on cryptography for a graduate class, I was surprised by what I learned.

Cryptography has been used from ancient times through the Industrial Age to the modern day. It's been used for military, diplomatic, criminal, and commercial purposes.

In the simplest and oldest form, Greeks used strips of paper wrapped around sticks of a certain size called a scytale - rhymes with Italy.

Julius Caesar is one of the first known users of the simple letter substitution method. The modern day cousin is ROT13.

If he had anything confidential to say, he wrote it in cipher, that is, by so changing the order of the letters of the alphabet, that not a word could be made out. If anyone wishes to decipher these, and get at their meaning, he must substitute the fourth letter of the alphabet, namely D, for A, and so with the others.
—Suetonius, Life of Julius Caesar

Hiding messages (steganography) is as old as the ancients. An example would be a tattoo on a shaved head. The hair would grow back hiding the tattoo. A modern example is hiding text in the pixels of a digital image.

Charles Babbage is a name taught in every into to computer science class as a pioneer in computing machines. I never knew that he helped the English during the Crimean War by breaking cryptological codes.

Mary "Queen of Scots" was caught when one of her secret codes were broken.

The Voynich Manuscript may have been an elaborate hoax to defraud a king, who had a interest in mysteries like coded messages, out of a large amount of gold.

A mob boss used encrypted messages to give out orders to his lieutenants and was arrested when the police cracked his amateur code.

Cryptography is thousands of years old and is used all around us everyday.

Programming as a Social Activity

What do we imagine when we consider the individual programmer? There are many stories that liken the programmer to the cowboy who finds himself in a small remote town rife with lawlessness and misery. The cowboy grudgingly accepts the job as sheriff, to right wrongs and otherwise do deeds of much heroism; riding off into the sunset, when the crisis has been averted, to the wails of the local townfolk who think they are losing their only defense against the chaos that comes with frontier life. Is this how individual programmers actually work or is this a delusion used to supplicate the ego of socially inadequate developers?

This continues my review of "The Psychology of Computer Programming" by Gerald M. Weinberg. The previous chapter Chapter 3 - How Can We Study Programming discusses the difficulty of studying behaviors which are hard to isolate, repeat, or tranlate into an experimental setting. Chapter 2 - What Makes a Good Program evaluates the subjective and objective criteria for judging programs. The beginning of the series of reviews is Chapter 1 - Reading Programs. Techrepublic.com has a review of the same book which reinforces this book's classic status.

In Part 2 of "The Psychology of Computer Programming", Weinberg describes three different ways that programmers are organized: the group, the team, and the project. Chapter 4 is titled "The Programming Group". He starts with the observation that when programmers work together in the same environment, they inevitably seek each other out for help or advice and expresses the premise that the lone programmer is at a serious disadvantage.

Formal and Informal Organization

The first lesson is that in any assemblage of people there are formal and informal groups. Formal hierarchies like an organization chart might be nice for the manager types but do not begin to describe the various interactions between individuals in a group. One good story is from back in the batch-scheduled era when it was difficult to know whether your job had run and its output was available, which was accomplished by posted completed jobs on a board outside the computer area. Programmers in remote offices might waste half an hour coming over just to find their results were not ready. As it happened, there was secretary who sat in a location which allowed her to see the result board. When a programmer who was waiting for a job to complete happened to call her for a date. When the conversation turned back to work, she mentioned that he must have work to get back to. He told her that he was waiting for a job to complete. She volunteered that she could see the board from where she was sitting and asked him in which job he was interested. This began an informal service which quickly became known to the outlying programmers. The service became popular enough to disrupt the work of the secretary and need the attention of the administration. Wisely acknowledging that the service could not just be cut off, they decided to implement a sort of job posting hot-line, even using the secretary's original phone number, where a recording would give the latest job completion posting. Here an informal and inefficient solution was replaced with a formal but efficient one.

This contrasts with a second story where a university computing center provided a common room for working on programming problems and an adjoining room with graduate students available to answer questions ("consulting services" was the term used in the book), and at one end of the common area were vending machines. When students complained about the noise from the crowd of students around the vending machines, the administration removed the offending machines. Not long after the removal of the vending machines, another delegation came to the administration with a complaint, there wasn't enough consulting services. As it turns out, the students who were making all the noise were actually discussing their programs and helping each other with them, answering all sorts trivial questions in an informal setting. The administration, unable to believe that the removal of the vending machines was the actual problem tried to increase the number of consultants available with little success as fewer graduate students were willing to deal with the ever increasing number of mundane and trivial problems. The formal solution was not nearly as effective as the old informal one.

Physical Environment and Social Organization

Does the environment in which you work affect your productivity? Companies are all about getting the most for the least so it is no surprise that in devising the seating arrangements of programmers, minimum cost usually trumps maximum productivity. There are exceptions like early Microsoft and their "every programmer gets an office with a door" mantra, to more recent examples like Fog Creek, who also take a programmer-first approach. In Weinburg's words,

"Someone should definitely study the depressing effect that the all-too-common half partitions have on programmer productivity. They manage to cut off all useful communication while permitting all disturbing sound and movement to penetrate."

Another example was the building that replaced the old manual elevator with an automatic one. This was unfortunate for the programmers because the old elevator operator had run an informal pickup and delivery service for them between their floor -- the eighth-- and the machine room -- the basement. They saved the cost of the elevator operator but cost their programmers much time every day going back and forth to the basement of the building.

Error and Ego

"If asked, most programmers would probably say they preferred to work alone in a place where they wouldn't be disturbed by other people"

"The ideas expressed in the preceding paragraph are possibly the most formidable barrier to improved programming that we shall encounter."

Programmers tend to get invested in the programs they write, attached to them we'll say. This causes behaviors that are counter-productive. What's wrong with "owning" programs, after all artists "own" paintings; authors "own" books; architects "own" buildings. When we go to the bookstore we can get a good idea about the quality of a book if it by a familiar author. Wouldn't the same hold true for programs and their authors?

"The admiration of individual programmers cannot lead to an emulation of their work, but only to an affectation of their mannerisms. This is the same phenomenon we see in "art colonies," where everyone knows how to look like an artist, but few, if any, know how to paint like one."

Another problem with the idea of ownership happens when we start to evaluate or judge a work. Art is to a large degree subjective so the artist can dismiss the opinions of critics. Can a programmer dismiss the judgement of a computer? If we took the "ownership" association to its logical end we would reason something like this:

"This program is defective. This program is part of me, an extension of myself, even carrying my name. I am defective."

Obviously that does not happen. Programmers do not quit just because of a single bug or logic flaw but they will tend to overlook problems and strive to prove the program is correct even in the face of mounting evidence to the contrary. Proving the program is wrong turns into a minefield of self-worth where bugs become the buried mines which will injure the pride of the programmer who can't help but react in defense of his own sense of self-worth.

"Thus, if we are going to attack the problems of making good programs, and if we are going to start at the fundamental level of meeting specifications, we are going to have to do something about the perfectly normal human tendency to believe that ones "own" program is correct in the face of hard physical evidence to the contrary."

This explains the unconscious motivations behind the resistance to code-reviews, pair-programming, or any other effort to get them to loosen their hold on "their" code. If we saw this type of behavior in a toddler, we would immediately recognize it as childish, as in "James doesn't want to share his code with the others." Will James feel like he is losing something if he has to let others play with his code? It would go a long way to explain things I've seen in my programming career.

Egoless Programming

So, what do we do? The manager could insist that the coders work harder at finding the bugs in their code. He could even go around and ask them to show him the bugs in their code. Applying even the smallest amount of psychology would tell us that this will backfire. The average person will feel he is on trial and very easily take it personally. If we can change the social environment of the group, we have a chance to affect change in the values of the programmers of that group. This is possible, we know of egoless programming groups since the very early days of programming.

"John von Neumann himself was perhaps the first programmer to recognize his inadequacies with respect to examination of his own work. Those who knew him have said that he was constantly asserting what a lousy programmer he was, and that he incessantly pushed his programs on other people to read for errors and clumsiness. Yet the common image today of von Neumann is of the unparalleled computing genius--flawless in his every action. And indeed, there can be no doubt of von Neumann's Genius. His very ability to realize his human limitations put him head and shoulders above the average programmer today."

Weinburg tells another story of a programmer from the early days of space tracking systems. "Bill" was confident in a loop and gave it to "Marilyn" to informally review, as was common practice in the group. Marilyn found seventeen bugs in only thirteen statements. Bill chalked it up to a 'bad programming day' and became more and more amused as each bug was found. He took it as proof that it just wasn't his day and used the rest of the day giving everyone a laugh at his expense. Marilyn, on the other hand, did not have any false confidence in her own ability and took the code to a third person. She knew that she had looked at it so much she wasn't going to be able to see any more errors. She needed fresh eyes. With others help, she found three more errors before the day was over. The epilogue was that no more errors were found in the code despite diabolical testing and being in production in over a dozen installations even after nine years.

Why aren't there more groups like this? Weinburg asserts that such groups are not an isolated case. They regard their practices as valuable proprietary information, implying they think other would copy them if given a chance. These groups are very satisfied and stable which reduces the opportunities for programmers to have encountered these groups. Also, gypsy programmers - who never settle in one place - encourage the myth that the best programming is the product of genius, to justify ever-increasing consulting rates.

The last word of this section is on how there is an advantage to making your code as readable as possible for other programmers for that means that those who come after will have a chance to learn from such code without feeling the need to have it deciphered or translated. So, the best code isn't the stuff that is hardest to read but the easiest to read. Easier to test, maintain, understand, and learn from; who could argue with that?

Creating and Maintaining the Programming Environment

One danger programming environments face is the tendency to fixate or lock into some behavior, habit, or tool. Programming language is a common example. Even if another language is better suited for a problem, the language of choice will be preferred. More people know it, there are more tools available (to the group), more library routines, etc. In other words, it's "how we do things here" which makes choosing a different language like paddling upstream, lots of resistance and little to show for a great deal of effort.

Another fixation is the social environment which either encourages or discourages egoless programming. If the new guy is ridiculed when asking another for help or advice, he is less likely to seek assistance the next time. If, on the other hand, someone pays him the implied compliment by asking him to look over a program, he is more likely to feel secure enough to seek advice.

"To a large extent, we behave the way we see people behaving around us, so a functioning programming group will tend to socialize new members to its philosophy of programming."

On the subject of egoless programming and management, Weinburg astutely describes the culture shear between common management and uncommon programming groups. Remember that this book came out almost 40 years ago; you can draw your own conclusions about how much things have changed.

"Managers tend to select themselves from the 'aggressive' component of society and have difficulty appreciating the fact that other people do not completely share their goals of money and prestige. They are especially at a loss to understand the smooth functioning of a programming group based on mutual respect for individual talent and cooperation in the common cause. Instead, the tend to view people as working for money or under threat -- as they themselves do."

Another example given is of a group that was particularly success and producing a new system. The achievement was noticed by the company's management who decided to give them a cash award. Typically, they wanted to give the award to the groups manager but were bewildered when the manager would not accept it unless the whole group got the award. The groups manager understood that the group acted as a team and that responsibility for success could not be attributed to a single individual. Other managers thought he wanted more money, others thought he was trying to setup a "prima donna" group. The company decide to force him to take it and break up the group -- which seemed to have unhealthy ideas. For those doubters out there, I have personally witnessed this same scenario in my career. The moral of the story? Again, Weinburg says it as well as anyone,

"Had the management been more aware of what this group had to offer, and had they been more flexible, they might have worked out a solution that would have permitted this group to influence the work of other groups in a favorable way. But this is not easily done by managers, who tend to feel that when work gets done it is the direct result of the actions of some leader of outstanding ability. Even when the manager appreciates the work of the group, it is not consistent with his own philosophy to see the productivity of the group as a property of the group, not as a sum of the contributions of the individual members."

Summary

To understand how programmers perform in a group setting, you must consider formal and informal structures, the physical environment, and even the social interactions in play between members of the group. These are lessons which are still worth learning today. The hard question we must ask ourselves is why we keep searching for new solutions when we have not addressed the issues identified four decades ago. I maintain that the Agile Manifesto or the Manifesto for Software Craftsmanship, is but a few of the efforts to awaken the courage of individual programmers to affect change around them, and cause a groundswell of change which might have the momentum to disturb the inertia of the status-quo.


Sample questions:

For managers: What is your honest opinion of people who are not trying to "move up" in your organization, but who seem satisfied with the kind of work they do and the amount of money they get? To what extent is your view influenced by your own feelings for yourself?

For programmers: Do you refer to your work as "my" program? Try passing one week without using the personal possessive in reference to programs, and take notes on the effects you observe.


p.s - These chapters are large enough that I may break them down so each section is its own post.

Chapter 3 - How Can We Study Programming?

This is a continuation of the review of Gerald M. Weinberg's book, The Psychology of Computer Programming. The review begins here for Chapter 1 - Reading Programs. The post on Chapter 2 can be found here.

What chance have we to understand the human factor? How do you study programming when the important majority of it takes place between one's ears?

Perhaps programming is too complex a behavior to be studied and must remain largely a mysterious process.

INTROSPECTION

Although some modern students of human behavior tend to discredit it as nonscientific, introspection has always been the first foundation stone of their science.

The author tells a story about a student having difficulty with a particular PL/I programming problem:

ANGLES(I)=2*ATAND(SQRT((S-A(IND(I,1)))*(S-A(IND(I,2))))/(S*(S-A(IND(I,3))))));

When it was finished the author asked the student to recall the thought processes -- the difficulties -- he had experienced with this statement, here is that list.

1. He had trouble getting the parentheses matched, because there were so many of them.
2. The original ANGLES(i) was a structure, not an arry, so the compiler complained of an illegal subscript list, but he had not been able to find the problem because there were so many subscript lists.
3. When the program finally got into execution, there were these further difficulties:
1. IND was a matrix on another page of the listing, and he had trouble finding it.
2. Even though the parentheses were now matched, one pair was in the wrong place and was most difficult to find.
3. The last difficulty turned out to be a problem of precision caused by capricious declaration of different data types, by the large expression, and by the division--which would not have been necessary if the two-argument form of ATAND had been used.

The student provided a number of insights, from the proper size of statements, the choice of data structures, to the design of compiler and execution-time diagnostics.

None of these insights could be obtained without introspection of this sort, yet thousands of programmers [millions now days - ed.] each day have theses same problems and simply grumble that they are having "bugs." Without the introspection, they will simply continue to have "bugs" until, in the end, the bugs will have them.

From this single instance of introspection, we could come up with "Laws of Programming"

1. The mind cannot cope with more than five levels of parentheses.
2. Compiler diagnostics should be more explicit.
3. PL/I precision rules are too complicated to use.

Although each of these statements might turn out to be a "law" in the psychology of programming, writing it on the basis of a single introspective example hardly qualifies it as a law. To be a "law," a principle must be explored so as to set limits to its application, because all laws have limits. Indeed, the limits are Usually more important to know than the laws themselves, and it is only by investigating a multitude of cases that limits can be set. Thus, without introspections, investigation would be sterile, but without investigation, introspection will be of questionable value in application.

OBSERVATION

One way to follow up introspection is by observation of what people actually do, as opposed to what they think they do.

Like the study of parentheses and how many levels of nesting programmers use.

One of the problems with observation, however, is that it tells us what people do do, but not necessarily what they can do.

If your census showed that programmers never nested parentheses more than 5 levels deep, does that mean they are unable to?

A second problem with observation is deciding just what it is we are observing.

All you know about the programmers who limit themselves to 5 levels of parentheses is a simple fact, to know why they don't use 6 or more would of course require introspection on the programmers part. If you were designing a language, would you limit the size of arrays to three dimensions simply because you've never seen anyone use more?

A third problem with observation is the problem of interference of the observer with the subject being observed.

This is called the "Hawthorne Effect". The act of observing workers actually affected their performance, a kind of uncertainty principle.

EXPERIMENT

Here is a very interesting section where the author describes the costs of conducting experiments on programmers using typical experimental psychology methods. How do you collect data without influencing the results. To a degree it is somewhat like the problem of testing the performance of a program. The modifications necessary to observe the programs use of memory or CPU time actually uses memory and CPU time so how can you know your results haven't been skewed?

You could do experiments using programming majors in school but would the results apply to professionals? You could study professionals but that could be prohibitively expensive. The author describes doing an experiment using one-quarter time of nine experienced programmers for three months. The average salary was $14,000 [I'm assuming annually - ed.], add in overhead (workspace, machine time, etc.) came to $20,000 apiece, or $1250 apiece over the course of the study. Add to that the experimenters salaries and so forth and the bill comes to $30,000 for nine subjects. [In 1970 dollars! - ed.] Using the Inflation Calculator ($30,000 in 1970 compared to 2009) this comes out to a cost of $163,254.90. Serious money, just to study programming.

... we must deal with one other problem, which is important because of a seldom-questioned view of programming. That view is that programming is an individual activity, not a social activity.

Not that the individual level is unimportant, but we might start by asking why, if the average programmer spends two-thirds of his time working with other people rather than working alone (yes, it's true!), that 99 percent of the studies have been on individual programmers.

The answer is that it is expensive to study programmers in groups. Plus, you can't put a number of trainees together and call them a 'team'.

Putting a bunch of people to work on the same problem doesn't make them a team--as the sloppy performance in all-star games should teach us.

The neglect of social effects also casts doubt upon all individual studies, since these studies force the individual to separate himself from his normal working environment. In one of our studies, one of the programmers came to me when he had finished coding and asked who could check his work. In his home group, this was standard practice at this point in development, but it was not allowed during the study -- lest it should "invalidate" the results.

Looking back, it seems that forcing programmers to work in isolation is like trying to study the swimming behavior of frogs by cutting off their legs and putting those legs in the water to watch them swim. After all, everyone knows that the frog swims with its legs, so why complicate the experiments with all the rest of the frog?

PSYCHOLOGICAL MEASUREMENT

For the present, most of the work in the psychology of programming is going to have to be "looking for questions."

I conjecture that we will move beyond looking for questions only when we start believing and acting on the questions that we've found over the almost 40 years since this book was published. This is definitely not a programming problem. When the software managers are able to dictate practices based on a whim or the local political winds, "We don't have time to do code reviews! Why can't you just make it work? I don't understand why it's constantly breaking!", you might start looking for answers in the abnormal psychology section of the library.

USING BEHAVIORAL SCIENCE DATA

Because of the nature of programming, there is not much hope that actual results can be transferred directly from other fields to ours. Our use of results has to be for insights, not for answers.

So maybe all those comparisons with engineering and construction are invalid on the face of it. We might look at Paul Graham's book Hackers and Painters for insight.

Finally, as we pass successfully through all this, we may find ourselves in a sufficiently objective frame of mind to examine some of the myths of programming -- the articles of programming faith. Faith, as Bertrand Russell pointed out, is the belief in something for which there is no evidence; and myths, as Ambrose Bierce once defined them, are the sacred beliefs of other people. Perhaps we shall simply carry away our old beliefs unchanged, but if just one unfounded programming myth should die as a result, this book will have been worth the effort.

SUMMARY

Common pitfalls:

1. Using introspection without validation.
2. Use of observation on an overly narrow base.
3. Observing the wrong variables, or failing to observe the right ones.
4. Interfering with the observed phenomenon.
5. Generating too much data and not enough information.
6. Overly constraining experiments.
7. Depending excessively on trainees as subjects.
8. Failing to study group effects and group behaviour.
9. Measuring what is simple to measure.
10. Using unjustified precision.

1. 
   

Several of these items have had some attention paid to them over the last decade. Extreme Programming was one of the first movements focused on groups of developers to get enough traction to garner a following. There are several similar movements, SCRUM, Agile, etc. Instead of assuming the problem was in the process that humans were following, they finally addressed the human factor as a first-order success factor (thanks to Alistair Cockburn)

The question is, when will we learn that we are the problem?


This ends Part 1 - Programming as Human Performance. Next up is Part 2 Chapter 4 - Programming as a Social Activity

Review - The Psychology of Computer Programming

I got a "new" book in the mail a few weeks ago and finally had time to crack it open, "The Psychology of Computer Programming" by Gerald M. Weinberg published in 1971. There is a Silver Anniversary edition that recently came out but I wanted a cheap copy in hardback so mine came from an online used book site. Why read a computer programming book that is almost as old as myself? Because it addresses the core issue of producing computer programs, the people who read, write, edit, maintain, or otherwise cuss at (other people's of course), code. People are the primary factor in all programs; before hardware, language, specifications, anything. If you don't understand how humans go about creating these abstract entities called programs, you will constantly be mystified by missed deadlines, frustrated by missing functionality, and stymied by endless scope creep. Enough of my pontificating, let's talk about the book.

Table of Contents

1. Programming as Human Performance




1. Reading Programs


2. What Makes a Good Program?


3. How Can We Study Programming?




2. Programming as a Social Activity




4. The Programming Group


5. The Programming Team


6. The Programming Project




3. Programming as an Individual Activity




7. Variations in the Programming Task


8. Personality Factors


9. Intelligence, or Problem-Solving Ability


10. 1Motivation, Training, and Experience




4. Programming Tools




11. Programming Languages


12. Some Principles for Programming Language Design


13. Other Programming Tools




5. Epilogue

"Computer programming is a human activity." A pretty bold thesis from the intro to Part I. Is there a mystique to programming? "Either you can program or you cannot. Some have it; some don't." Both quotes give you a good idea as to what is in this book, tackled expertly by Mr. Weinberg.

Chapter 1 - Reading Programs

Some years ago, when COBOL was the great white programming hope, one heard much talk of the possibility of executives being able to read programs. Weith the perspective of time, we can see that this claim was merely inteded to attract the funds of exectutives who hoped to free themselves from bondage to their programmers. Nobody can seriously have believed that executives could read programs. Why should they? Even programmers do not read programs.

I hear a similar story from when assemblers were introduced - as in, "With the development of assemblers, we won't need programmers anymore!" I believe similar statements have been propagated by hordes of 4th generation language and CASE salesmen.

"Programming is, among other things, a kind of writing."

This is not a very mainstream view in the programming world even though we work with constructs which are literally "languages".

"We shall need a method of approach for reading programs, for, unlike novels, the best way to read them is not always from beginning to end. They are not even like mysteries, where we can turn to the penultimate page for the best part -- or like sexy books, which we can let fall open to the most creased pages in order to find the warmest passages. No, the good parts of a program are not found in any necessary places -- although we will later see how we can discover crucial sections for such tasks as debugging and optimization. Instead, we might base our reading on a conceptual framework consisting of the origin of each part. In other words, as we look at each peice of code, we ask ourselves the questions, 'Why is this piece here?'"

The author begins examining a section of PL/I code showing how certain machine, language, and human limitations influence a program. Machine limitations like lack of memory to hold the entire problem set in memory at the same time causing the use of two loops instead of one. Language limitations like the lack of an end-of-file indicator which forces the operators to include a special character (or card in the 1970's punch-card centric world) and causes the programmer to account for the special character in code. Programmer limitations like not really understanding array notation of the language, in this instance PL/I. As a program is modified over time, machines change, languages are updated, and programmers come and go.

"And so, some years later, a novice programmer who is given the job of modifying this program will congratulate himself for knowing more about PL/I than the person who originally wrote this program. Since that person is probably his supervisor, an unhealthy attitude may develop -- which, incidentally, is another psychological reality of programming life which we shall have to face eventually."

Some programs have inscrutable logic like the use of special characters which are ordinarily invalid; "magic numbers" used for interim states for some long-forgotten problem.

"Once the patch was made, it worked so well that everyone forgot about it -- more psychology -- and there it sat until unearthed many years later by two archeologist programmers."

To different versions of the same PL/I program are compared, the first includes many limitations of which we've already spoken, the second much improved by removal of the previous limitations. Of the comparison,

"When we look at the difference between Figures 1-1 and 1-4, we might begin to believe that very little of the coding that is done in the world has much to do with the problems we are trying to solve"

Would we be any better off if we could use the latest code (Figure 1-4) as our spec?

"Specifications evolve together with programs and programmers. Writing a program is a process of learning -- both for the programmer and the person who commissions the program. Moreover, this learning takes place in the context of a particular machine, a particular programming language, a particular programmer or programming team in a particular working environment, and a particular set of historical events that determine not just the form of the code but also what the code does!

In a way, the most important reason for stufying the process by which programs are written by people is not to make the programs more efficient, more compact, cheaper, or more easily understood. Instead, the most important gain is the prospect of getting from our programs what we really want -- rather than just whatever we can manage to produce in our fumbling, bumbling way"

Hopefully the reason to study a 30+ year-old book is apparent; those who fail to learn from history are bound to repeat it.

Let's study historical mistakes so we can make our own new mistakes instead of repeating mistakes of programmers long-retired.

The rest of the book is just as rich in lessons we can still take to heart. By approaching the book chapter by chapter, I'm hoping to increase my chances of getting all the way through without writing a 50-page article all at once which would never get finished.

Here is the link for the next chapter: Chapter 2 - What Makes a Good Program

Behind every great man...

I don't normally think about book reviews as a subject for this space but Galileo can be considered an Honorary Codewright. So with that said, here is a review I wrote this past summer...

Over the weekend I finished reading Galileo's Daughter by Dava Sobel. It was a fantastic read. It's more of a biography of the great man but told really well. I was impressed with the historical research from political/military events around Europe to the intrigue of the Catholic church. Even minor things, like getting to hear about his family's financial troubles or the details of printing a book in those times brought enlightenment. I never knew that cloistered nuns in the 17th century had to deal with money to such an extent. There are several things that really come through. The man was as devoted a Catholic as you'd ever meet. The idea that he had gone against it brought him to his knees. In contrast to his faith, he also had a deep desire for the truth and this legendary collision between faith and science, centered upon this one brilliant and pious man, speaks volumes about human nature. What you will not forget though is his relationship with his exquisitely minded (his words) oldest daughter Virginia who took the appropriate name Maria Celeste when she took her vows. Even though his letters to her do not survive, we have a treasure trove of her letters to him that reveal as devoted a daughter as any father could ever want. That she reveres him and dotes on him is even more incredible considering it was all done from within the walls of the San Matteo convent. From the mundane news of her fellow nuns to the huge responsibilities of taking care of Galileo's estate and accounts while he was in Rome facing charges of heresy, she was always there for him as he was for her; ever his confidante, his guardian angel, his supporter, his devoted daughter. The author closes the story with such care and brings the relationship between the great man and his reverent daughter full circle in such a way that, like the motion of the stars he strove most of his life to reveal to the world, the soul of the reader will be forever moved.

This is the short form. I need to write a longer review, hopefully later this week.