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.
Tags: fowler, productivity, software
Entries (RSS)
April 13th, 2008 at 9:58
Good post. I agree with you, although I see where Fowler is coming from: the idea that there are best practices leads to certification, which leads to bureaucracy and inefficiency.
I think identifying the context is key here, and you mention this in the end. For each team, customer, and software project, there is probably one best approach, or school of software, as Fowler calls them. We don’t know them yet; as scientists we hope to discover them. For now, stating that all schools might be valid for some context is the best we can do.
April 21st, 2008 at 6:22
Interesting….keep it up.
April 27th, 2008 at 23:39
from my limited (practical only) experience it was always about getting something done to give the impression of progress to clients - seems cynical but the phrase “we are 95% complete” is very misleading on its own - what are the metrics? and what are the criteria for success should be every client’s question - how you teach that is a tough problem