Semantic Werks

Martin Fowler, respected senior figure in software engineering practice, has a post describing ’schools’ of software development. A school in this sense is a group of like-minded individuals who subscribe to common philosophies. For example, Fowler describes himself as belonging to the object-oriented, agile-practitioner school (although this is necessarily vague).

I like this notion, particularly because it seems to model the idea of software as craft. That is, software development is somewhere between art and engineering. Other crafts might include cabinetry, armor-making, carpentry, and so on.

Fowler’s post, however, seems to imply that all schools (or at least those that have some basis in practice and can enumerate their shared beliefs) are equally valid. As an aspiring software researcher, I would disagree (note that my response isn’t grounded in any empirical experience). My feeling is that in fact, there are better sets of practice (perhaps for certain situations) and worse ones.

Putting aside those schools that are clearly created merely to serve the needs of a particular vendor, it is my fervent hope that at some point, we can define measures of success that will enable us to say where, and when, a particular approach is useful. For example, is static, type-checked development always worse than interpreted, loosely-typed development? Is test-driven development always best? When is it useful?

My sense of reading the reports of practitioners, and the research literature and history of the field, is that we still do not have a good sense of how to even ask these questions, let alone answer them. For example, Fowler references a post of his, “We Cannot Measure Productivity“, wherein he makes the point that it is (impossible? difficult?) to measure how productive a programmer or team is. I agree. But still, that doesn’t mean that there isn’t the good old Gaussian (power-law?) distribution behind a series of software projects. Namely, there are good projects and bad ones, and a bunch of mediocre, ‘met expectations’ projects in the middle. So presumably there is some way to measure these outcomes.

I think there’s a hint to an approach to these issues — specifying measures of success, productivity, etc. — in Fowler’s statement that ”any true measure of software development productivity must be based on delivered business value”. Business value may be an even more vague concept, but at least there’s a starting point. I would apply the same standard to software schools. Your school is superior, in some context, if it can deliver more value to the customer than a competing methodology. While Fowler is pessimistic on our ever being able to accurately measure business value, I’m more naive. I think we can, and should try.

I just returned from the ICSM conference and associated workshops in Paris, France (very nice, thank you). I have many notes on talks I saw, but herewith a few impressions:

ICSM is about software and machine artifacts, not requirements. Requirements come from on high, and the impetus for maintenance tasks is generally assumed to be well understood. It seemed a little like solving the problem of getting suburbanites to a downtown office by improving the highway signage, or improving offramps, but ignoring urban rail as an option altogether.

A discussion at the workshop on evolvability spurred me to consider the ’smart-monkey syndrome’. My contention is that building software, while hard, is not the hardest problem. I think there is a lot of evidence for this, starting with Brooks’s law, which is all about the external effects on software development, specifically communication.

Along the same lines, Bruce Eckel posted a neat thought-experiment, asking, “If Microsoft, with all the money and smart people it has, can’t release cool applications more than once every few years, than who can?” Several responses disagree, suggesting Microsoft is actually quite innovative. However, one of the respondents posted an argument with which I wholeheartedly concur, namely that it is again the external factors — multi-national lawsuits, legacy support for code from the 80s, internal communication, device support, etc. — that is the real bottleneck. This, I think, supports my contention that the building of software — e.g., GMail — is the easy part. I am almost certain that Microsoft engineers have had many of the same ideas as Google, but external reasons prevented their realization, such as corporate strategy, marketing, etc. Much as I have shied from the business side of software as fuzzy and pseudo-scientific (meaning that many of the claims in the literature are wholly unsubstantiated by evidence), I am coming to realize that it may be the one aspect that matters the most - and certainly more than language choice.