The Problem With Software: Why Smart Engineers Write Bad Code (The MIT Press)

by Adam Barr

At the same time, the gap between academia and industry has continued to widen, so that each new idea becomes less moored in research, and software drifts further from, not closer to, the engineering basis that Shaw was hoping for.

The designers of C took great pains to ensure that the language did not insert any roadblocks to performance. The result is a language that takes care of the grunt work of mapping variable names to memory locations, handling loops and IF statements without requiring explicit GOTOs, and passing parameters to functions, without getting in the way of anything else. C has been characterized as a thin wrapper around assembly language.6 This could be meant as both a compliment and insult, but it perfectly fit the needs of the transition from software running on mainframes to software running on PCs, once the complexity of that software got much beyond DONKEY.BAS.

By another appalling lack of serendipity that I won’t get into, you can set the return address to point into an earlier part of the buffer itself, and the computer will happily jump to any return address, even one that is in the area reserved for the stack versus where code is normally loaded. So the malicious finger request (such messages are generally known as exploits) can send over the actual code that it wants to run (known as the payload) in the same bogus finger message that it uses to overflow the stack buffer.

I thought this was a short and lucid explanation of why C programs tend to have security problems.

C offers abstractions which it does not in fact support: Arrays remain without index checking, data types without consistency check, pointers are merely addresses where addition and subtraction are applicable. One might have classified C as being somewhere between misleading and even dangerous.

This is a Wirth quote and a good insight. "Offers abstractions it does not in fact support" is just a beautiful put-down.

The book Microsoft Secrets, which came out in 1995, fills in some of the background: the first test teams were set up in 1984; there were expensive recalls of two pieces of software, Multiplan (a spreadsheet, which was a precursor to Excel) in 1984, and Word in 1987; and in May 1989, there was an internal meeting on the optimistic subject of “zero-defects code.”27 The

Possibly I should read this book.

Developers would strive to reach “code complete,” meaning that all the code had been written and successfully compiled, and if the stars aligned just right, might even be bug free. They would then hand the software off to the tester, with the implication that they had done their part and the tester was responsible for figuring out if it worked or not. Code complete is not an inconsequential milestone; it meant that none of your early design decisions had painted you into a corner, and the API you had designed to connect the pieces together was at least functionally adequate. But the problem was that code complete was viewed as “the developer’s work is done, pending any bugs received; if the software ships with bugs, it’s the testers’ fault for not finding them.”

I liked this explanation of what code-complete does or doesn't mean.

In Simula, you would create a new object of a given class (which is also known as instantiating an instance of that class) using the keyword NEW followed by the name of the class, like this: MyObject :- new MyClass; where :- is known as the reference assignment operator

That's....a remarkably modern syntax and possibly more tasteful than C++/Java.

Henry Baird, one of my on-loan-from-Bell-Labs professors at Princeton, points out that API design requires social skills, because you have to be aware of what assumptions your callers may make.

Fisher’s fundamental theorem states—in terms appropriate to the present context—that the better adapted a system is to a particular environment, the less adaptable it is to new environments. By stretching our imagination a bit, we can see how this might apply to computer programs as well as to snails, fruit flies, and tortoises.”21 In other words, the more you optimized your program for speed, the harder it was to modify it later to accommodate extra functionality.

Code, by pure tonnage, is primarily dealing with things going wrong, despite the fact that nothing goes wrong the vast majority of the time that it runs.

On the question of making your code flexible to anticipate future changes, XP is clear: don’t do it. Write the code for the requirements of the feature you are working on now, and if the requirements change, because of a new feature or user feedback, modify the code then. Since the code will have good unit tests, you can make these future modifications without worrying about accidentally breaking something because your understanding of the code is not fresh in your mind. And until you have new requirements, you won’t know what changes are needed, so it is foolish to attempt to anticipate them now.

This of course fails as soon as you have "public" APIs -- that is, as soon as your code has callers whose code you can't see or test.

For what it’s worth, I have read several books on Scrum (including Schwaber’s, which makes no mention of this), become a Certified Scrum Master, and taught Scrum to teams inside Microsoft for several years, and I never heard that Scrum was unsuited to procedural programming or observed problems with Scrum that were unique to teams using procedural languages.

Scrum is not a progressive way of managing software projects; it’s a logical reaction to the current state of software development, which attempts to contain the damage by not overpromising to customers.

How does SEMAT propose to address this? Not, initially anyway, by actually doing any experimental evaluation and validation. As programmer and former professor Greg Wilson comments in his “Two Solitudes” keynote talk from the SPLASH 2013 conference, the SEMAT book doesn’t cite a single empirical study.55 Instead, between the three forewords and twelve pages of testimonials at the end, it attempts to abstract out the common parts of software process management methodologies into a metamethodology, which could then be used to diagnose flaws in your actual methodology. Given that Agile is already somewhat removed from the actual problems of software engineering, taking a step back does not get you any closer to the essence.

When designing hardware, a company is doing “real” engineering: electrical engineering has built-up knowledge about circuit design, heat dissipation and power, and other topics that can’t be solved with a “this worked for me last time” approach. Companies have to rely on research, both from academia and industry. In addition, you can’t easily make changes late in the design of hardware the way you can with software; up-front design is worth the time. Presumably a hardware company would approach a software problem with the same disciplined approach. Given that, it is understandable that early software engineering, driven by a combination of mathematicians in academia and hardware companies in industry, started down the path taken by other engineering disciplines, and you can see the results of this in the literature produced during that time. An observer in 1975 would have had reasonable confidence that the trend would continue, and that in a few decades, things would be figured out, codified, and then taught to students and reinforced through professional training. That is not the way it turned out, to put it mildly. What happened?

This is a really good point and is one of the core questions the book tries to answer -- I wish the author had put this point up early; it would have helped motivate some of the biographical material that otherwise appears self-indulgent.

Knuth has stated that he feels that at the beginning of the 1970s, academics were good programmers and industry professionals were not. Yet during that decade, as the scope of software that industry wrote increased, the situation reversed itself, and by the end of the decade the academics had drifted out of sync with what was going on in industry and restricted their programming, and therefore their area of expertise, to smaller programs that were no longer useful for generating advice for industry.21 Basili stated it as, “Researchers solve problems that are solvable, not necessarily ones that are real.”

Some people claim that the instant you feel you need a comment in your code, you should instead move that code into a separate method with a sentence-length, camel-cased method name, with said method name serving as the complete documentation; these people walk among us, undetected by the institutions meant to protect a civil society.

The IEEE Computer Society, a professional association with similar goals to the ACM, created the Software Engineering Body of Knowledge (SWEBOK), which is summarized in the book SWEBOK 3.0: Guide to the Software Engineering Body of Knowledge, known as the SWEBOK Guide (the ACM was initially involved in SWEBOK, but pulled out after disagreement on the direction it was taking).31 This initiative has a cargo cult aspect to it; other engineering disciplines have bodies of knowledge, so maybe if we create one of our own, we will acquire the engineering rigor that they possess. Essentially the IEEE has assembled the current wisdom on software engineering, without passing judgment on the actual value of it.

“In my career with over a hundred papers, there is something truly new (having no obvious antecedents) in only one of them. And I conjecture that is one more than average.”

Quoting the author's father, a professional mathematician.

I am not entirely blaming universities; one of the main reasons they do not know what to teach is because industry is too self-satisfied and complacent to interact with academia. If you ask companies what they would like colleges to teach, they will likely start talking about so-called soft skills: communication, being on time, and working well with others. That’s nice, but it’s not surprising that a bunch of adults, who now have families, mortgages, and other responsibilities, are able to recognize that college seniors aren’t quite as mature as they are. It’s more difficult to determine what technical skills may be lacking in college graduates, particularly when those same skills may be lacking in the experienced employees as well.

If students wind up working in an Agile Eden, on a small team that stays together for a long period of time, with a single customer who is engaged in overseeing their software, calling well-documented APIs in a well-understood environment—then great, they can dial back their application of software engineering principles and relive their halcyon days. But if not, they need to have the core engineering knowledge. It’s a lot easier to know the underlying principles and choose not to apply them than it is to not know them and be in over your head.

(Knuth named the first implementation of this system “WEB,” explaining—this was in 1984, remember—“I chose the name WEB partly because it was one of the few three-letter words of English that hadn’t already been applied to computers”).

There was a team in Microsoft Research that examined software engineering, generally using Microsoft as its population of interest, but the results, although considered to be thought-provoking tidbits, rarely had any uptake back in the product groups. It was a variation of the Gell-Mann Amnesia effect, where people realize that news stories about their areas of expertise are simplistic or inaccurate, but completely trust news stories about topics they know nothing about. If you told members of one Microsoft team about the engineering experience of another team, they would immediately be able to identify—because of their knowledge of the internals of Microsoft—the ways in which that other team was different from their team, and therefore dismiss the guidance as not relevant.

Certification and licensing should happen, but not right away; what is important is that industry and academia agree that they are a goal to strive for. Maybe it’s not required for everybody, and maybe you need a master’s degree, but we should set it as a long-term goal.

I have doubts about this.