So you’ve just been handed a big plate of spaghetti code to take care of, and you’re feeling overwhelmed. Michael C. Kasten has some great advice on how to deal with this skillfully. It’s short and to the point, so I won’t repeat it. But it’s definitely worth reading.

A recurring theme has emerged in what I’ve been reading the last few days. It boils down to the differences between software based on a clean, logical algorithm, and software based on arbitrary rules.

The topic first arose in a conversation I was having with Chris Conway over at Code Reads, exploring the pros and cons of functional programming. Chris said that he used FP every day, programming in OCaml, and loved it. It wondered if the reason he loved FP so much and I found it so unappealing was that he spent a lot of time working on problems that had elegant algorithmic solutions, whereas I spent so much time working on code that was (comparatively) a hodge-podge of arbitrary rules. This difference seemed to me to be a key distinction between “academic” and “business” software. Chris did not agree with me, or perhaps simply thought other factors (performance and library availability), were more important. We left it at that.

Read the rest of this entry »

While I’m working on my next big post, here are a few things worth reading.

Scott Rosenberg’s post on ambiguity was right on. Ambiguity is a double edged sword - it can make things elegant, or intractable. Scott’s insight is very sharp, as usual.

Last year, Basil Vandegriend put out a concise and helpful post on writing good unit tests. Most people agree tests are important, but many do not know precisely how to make them work. Basil addresses real issues, and gives good advice. I wish I had read this ten years ago.

Basil’s latest post on the top five essential practices for writing software is also bang on. It is a quick must read for programmer trying to make the leap from just coding to professional software development.

Code Reads 5 takes us from Dijkstra to Knuth, and his humorously titled “Structured Programming with Go To Statements“. In it, Knuth addresses how the field seems to have missed the real point of Dijkstra’s structured programming, and instead focused on mindlessly eliminating “go to” statements. Knuth quotes Hoare when saying the most important point is “the systematic use of abstraction to control a mass of detail”, not eliminating a particular programming tool.

The main topic of Knuth’s article is not abstraction, but rather examining the uses of “go to” that improve a program, and how newer (in 1974) language constructs (like break statements and case statements) can almost always be used to express the meaning of those “go to” statements. In fact, he ends by saying that although he would personally like to keep “go to” available in higher level languages, he would probably never need to use it.
Read the rest of this entry »

Edsgar W. Dijkstra’s “Notes on Structured Programming” is definitely a meal. Its quite a lot for one Code Read. So I broke it into two parts. First, we had the appetizers, now here’s the main course.

Program families and evolving software

Dijkstra points out that programs exist in large families of similar programs. When we make changes, we are transforming it from one member of the family to another. By thinking of programs in this way, the importance of a programs structure becomes even more important - because we would like the families to share not just code, but also correctness. If the structure is confusing, the changing the program is difficult because lots of code changes and that code all needs to have its correctness reexamined. A simply structured program tends to require changes in areas that are already well-isolated, thus less code changes, and we need to think less about the correctness of the new code and the code that depends on it. (Similarly, although Dijkstra does not make this point explicitly, a layered structure can make it more clear which areas rely on the changed code, so they can also be verified easily.)
Read the rest of this entry »