Skillful Software

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.

Then this morning I came across a similar discussion. “Algorithms vs. rules of thumb” is the starting-off point in James McGovern’s response to James Tarbell’s discussion of engineering vs. architecture. James McGovern says:

It is hard to find stable abstractions when the people who dictate requirements come and go in the organization or act seemingly capriciously. Applying abstractions from math and geometry is much easier because God does not change the rules. However, the Gods of Business flip all over the deck. Business culture is shaped by sales, and selling is generally an “intuitive” discipline. Thus, explicitness is often not expected and not honed by management. I am of the belief that this is the number one impediment to Business/IT alignment and therefore those who pursue alignment will always be banging their head into a brick wall.

And James Tarbell:

The people side [architecture as opposed to engineering - AS] needs to be focused on 3 things:
- usability and making business automation better for users
- not overengineering UMLs to forward engineer the best and fewest lines of codes which does not directly impact the end user 9 times out of 10.
- leading developers and stakeholders through the quagmire of multiple technology implementations.

Both of them are acknowledging the great difficulty in managing the arbitrary rules of business. But there are whole fields of software which are much less plagued by this problem. Writing a web server, for example, or scientific software, or a file system. All of these areas have more opportunity for designing elegant abstractions than are offered in modeling a typical business process.

So I think “academic” vs. “real world”, “off-the-shelf” vs. “one-off”, and many more distinctions, all revolve around the question of whether the software leans more toward finding a general algorithmic solution or simply creating arbitrary rules. This is really the great software divide.