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.

When doing software design, a common question is how much “advanced” functionality to build in, and how much to let the users create themselves using a simple set of tools. For example, a reporting module could have many canned reports, or could have a tool which allows users to build reports themselves (or both). Often the canned reports can do things more efficiently or elegantly than user-built reports, because they have access to the full internal workings of their environment. Designers of programming languages face a similar problem - how much should be included in the language, and how much should be left to users to build. In the latest of Scott Rosenberg’s Code Reads Guy Steel shows how the ideas of the open source movement influenced the designers of Java to think in terms of growing a language to avoid this dilemma.

Read the rest of this entry »

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 »

Scott Rosenberg’s book Dreaming in Code, and the Code Reads section of blog have really inspired me to think and read more about my job. The “assigned reading” for Code Reads has been really great, so recently I started on a tangent - a book mentioned in Code Read 6, titled Bringing Design to Software, by Terry Winograd. Prof. Winograd teaches software design at Stanford, and the book is a collection of essays that came out of a 1992 workshop on software design. So far, I’ve only read the introduction and the first chapter (which was the text for Code Read 6). So far the ideas have been very interesting, but a word of warning if you’re thinking of purchasing this book. Reading it is a chore because of the awful printing. Addison Wesley, the ACM, and Prof. Winograd could have done so much better than reproducing these low-res weirdly half-toned pages. It looks like the master pages were printed on an old 16-pin dot matrix printer, and designed using “creative” shares of gray. But I’ll forgive them the bad printing if the rest of the book is as interesting as what I’ve read so far.

Before I get too into that book, though, I want to tell a quick story.
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 »