Thanks to Frank Kelly for pointing out James Carr’s great list of testing anti-patterns - things to really avoid when writing automated test cases. This is definitely a page 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.

The ever evolving “The Cathedral and the Bazaar” by Eric S Raymond (aka CatB) has become something of a lengthy read. Scott Rosenberg’s Code Read 8 dives on in, and rightly describes it as a “classic essay” and says it “has proved its importance” in the literature of software development. I first read it several years ago, it was considerably pithier then. However, it is still full of important ideas.

Cathedrals and Bazaars

The most important idea is its title track - two different ways to build software. In the “cathedral” style, a master architect and a small group of hand-picked skilled craftsmen work toward a grand vision with lots of direction and coordination. This is the traditional model of software development. The “bazaar” model, which is common to many open-source projects, particularly Linux, is one in which there are no hand-selected craftsmen, and no master plan. Instead the people in power select the best contributions from those people interested and able enough to contribute something worthwhile. The direction in which the project evolves is determined by the availability of volunteers willing to push it in that direction, as well as an entity, often an elected committee, which acts as an editor.
Read the rest of this entry »

In 1985, David Parnas resigned from his position on a panel convened by the Strategic Defense Initiative Organization, which was overseeing the “Star Wars”, or SDI anti-ballistic missile defense program. Along with his resignation he submitted several short essays explaining why he thought the software required for Star Wars could not be built, at that time or in the foreseeable future. Those essays were later collected and published, and are the subject of Code Read 7.
Read the rest of this entry »