Software Cadence

I was intrigued by Bob Muglia's use of the word "cadence" in an interview last week about the future of Silverlight.

“As with anything as it matures, the (delivery) cadence changes.”

Mr Muglia is the Microsoft President in charge of the company’s server and tools business. The interviewer, experienced Microsoft commentator @maryjofoley, interpreted this to mean that the delivery pace of Silverlight is slowing [Mary-Jo Foley, Microsoft: Our strategy with Silverlight has shifted ZDNet 29 October 2010].


Yesterday, Muglia issued a statement in which he apologized for any surprise, controversy or confusion resulting from what he said, and sought to "expand" and "emphasize" some important points. The comments below this statement display a range of responses from reassurance to betrayal - this debate seems to be more about perceived commitment and trust and developer morale than about the technical issues. Muglia didn't repeat the words "maturity" or "cadence", and to date only one comment has appeared demanding that these words be clarified [http://team.silverlight.net/announcement/pdc-and-silverlight/].


Cadence is an ambiguous metaphor in this context. In music, it refers to the last few chords in a piece of music. Traditional cadences were very quick, but Beethoven introduced cadences that continued for a fair while, loudly repeating the last few chords over and over again without developing any new material, and this style is also found in some rock music. An entirely different meaning of the word is found in cycling and running where it means rotation speed - in other words, the number of times the pedals go round, or the number of times your feet strike the ground. I'm guessing Muglia is using the word in this sense, as a metaphor for the frequency of software release.


Just checking Wikipedia (where else?) I learn that elite runners don't vary their cadence much - if they want to go faster or slower, they simply put more or less energy into each step, rather than changing the number of steps - and this might be a relevant pattern for the software industry as well. However, I can certainly think of software products that continue to be upgraded regularly, even though each release seems increasingly trivial, almost empty of meaningful content, as if we were following the Beethoven cadential style.


The relationship between cadence/maturity and developer confidence is a peculiar one. One might think developers would prefer tools and platforms to remain stable, without a constant flurry of new complicating features, but there is clearly a fear that the rest of the developer community will abandon the platform as soon the new features stop coming. In other words, the viability of a platform relies on its not being perceived as mature or even maturing, and therefore a platform that wishes to retain the confidence of its developer community must get progressively more complicated and difficult to use, because of the accumulation of features that have been added for the wrong reasons.



I don't like that conclusion, I hope it's not true, but if it were true it would certainly explain a few things.

UK Government's love of IT complexity

@tonyrcollins has been posting quotes on his blog from the BBC Radio4 File on Four programme about IT public sector projects in the UK, including the IT problems hurting farmers.

• A terrible price for the Government's love of IT complexity?
• Bright people at IT suppliers treat ministers as playthings 

So where is that podcast? I'm sure I must have already downloaded it ...

---

The programme opens with a comment by Edward Leigh, the retiring chairman of the House of Commons’ Public Accounts Committee.

"We the taxpayer are paying enormous sums to people for these IT projects, to run them for us, and to waste money for us. So I think once a general election is over whoever wins I hope will take a scythe through all these precious IT systems."

Here is Dr Phyllis Starkey MP, chair of the parliamentary select committee, talking about a failed system for the fire service.

"There have clearly been massive mistakes about the way in which the project was first formulated and the way in which the contract was originally drawn up with the main contractor and they've led to huge delays and massive additional costs to government and to the various fire authorities."

Aha, I just got to the bit where Tony Collins himself appears on the programme. For those of you that don't know him, Tony is the executive editor at Computer Weekly and has been a public observer and critic of public sector IT in the UK for a long time. Very sound.

I was particularly interested in Edward Leigh's suggestion that ministers are subject to the illusion that it is easy to add functionality.

"They’re very short-termist. They want to create a quick impact …[and] are very naive about IT systems and the cost of IT staff, so they’re taken for a ride by very bright people who earn very large salaries in the private sector running these companies."

“Ministers come they go and they add onto these things like a Christmas tree. You need one simple – piloted – [system] … you stick to it. Rough-justice politicians just keep changing their minds – constantly new ideas – and of course they are just playthings for the private sector."

But will anything change after the election? Tony Collins sounds a note of caution: A few big IT suppliers may have Tories over a barrel. So more of the same then?

Blame Powerpoint

@cybersal asks @RSessions a different sort of s/ware complexity question from his usual stuff: "How would you compare complexity of PowerPoint 2007 v 2003?"

The first point I want to make in discussing this question is that there are two different things, both called "PowerPoint". One is a lump of shrink-wrapped software, which I call technology-as-built. The other is the PowerPoint that people actually use, which I call technology-in-use. (Fans of Chris Argyris will recognize the parallels with espoused theory versus theory-in-use). If different groups or communities use PowerPoint differently, there may be many different PowerPoints-in-use corresponding to a single PowerPoint-as-built.
 

The distinction between technology-as-built and technology-in-use is extremely important for technology adoption and management. (My favourite example of this remains Lotus Notes, which for some time after its initial release was mostly used in pretty boring and unimaginative ways, merely as a jumped-up file management system. I guess it took at least two years before the technology-in-use started to catch up with and then exceed the intentions of the Lotus design team.) My notion of technology maturity is based on a stable relationship between technology-as-built and technology-in-use.

However, this distinction is largely ignored by IT analysts, who try to rank the "vision" of the software producers but entirely overlook the "vision" of software consumers. This is related to my point about Venturesome Consumption (Oct 2009).


By the way, the distinction is implicit in my post yesterday, Blame Excel, where I distinguished between blaming things on Excel itself (technology-as-built) and blaming things on people using Excel stupidly (technology-in-use). Is Microsoft responsible for how Excel or PowerPoint are used? Clearly software providers cannot be blamed for the stupidity of their customers, but Microsoft clearly has a strong interest in promoting good use of its products, and providing some protection against bad use.

Now here's how this distinction applies to the question of software complication and complexity. Let's acknowledge that each successive version of PowerPoint-as-built has loads more features, new menu options, design styles and so on. But let's also acknowledge that many PowerPoint users are still using

• the same limited subset of features
• the same font (Ariel)
• the same style (bullet points, like this)
• the same clip art (those horrible cartoon men). 

When people talk about Death-By-PowerPoint, they are generally talking about PowerPoint-in-Use. It is clearly possible to produce lively and informative PowerPoint presentations, but many people (including Bill Gates) don't seem to find this very easy.


So there is a growing gulf between the technology-as-built and the technology-in-use. This is where the unnecessary complexity gets in. The more complicated the technology-as-built,  the greater the risk of poor results from the technology-in-use.

---

Update: I just found a presentation by Professor Yannis Gabriel called Against the tyranny of PowerPoint: Technology-in-use and technology abuse (2008).



Related Posts: The PowerPoint Collection

IT Complexity

According to @RSessions, "IT Complexity is a tax paid by everybody that benefits nobody."

Well not quite. @neilwd lists a few exceptions: vendors, integrators, analysts.

Roger's mission to eliminate complexity is fraught with two major difficulties. First, the number of powerful stakeholders who appear to benefit from complexity. Neil mentions a few obvious ones.

And second, the wide range of factors that cause complexity. Some forms of complexity may be justified in terms of requisite variety. Some forms of complexity emerge from a history of decisions that made sense at the time. And some forms of complexity may actually be caused by clumsy or one-sided attempts to eliminate complexity - for example, arrangements to protect one party in a procurement contract (especially in the absence of trust).

@patrickdlogan offers an analogy for IT complexity - the levees in New Orleans: no budget to fix them, but just enough budget to work most days, make more complex. Roger replies: Good analogy. But unlike most IT projects, the New Orleans' Levees worked at least for a while.

Actually, most IT projects work after a fashion. Where IT projects are regarded as failures, this is usually because something has gone wrong with such factors as cost and quality (value-for-money). One of the lessons for IT from Hurricane Katrina is about the ability of a large integrated system to withstand unexpected events. See my posts on Efficiency & Robustness 1, 2. See also my post on Processing New Orleans mail after Katrina.

Conservation of Complexity

An interesting debate between Mike Garrett (a member of the SAP practice at the Data Management Group) and Andy Hayler (founder and chief strategist of Kalido).

In an article on SAP Business Intelligence and the Conservation of Complexity, Mike advocates reducing the amount of complexity presented to the broader end-user base. He bases his argument on the principle of conservation of complexity, which he expresses thus:

"The total amount of complexity in an information system remains constant. In other words, complexity can be transferred from one party to another, but it cannot be created or destroyed."

In a blog posting on Complexity Conservation, Andy accepts this principle, but disputes Mike's conclusions. He argues that complexity can be managed through an appropriate BI platform.

However, I think the principle is mis-stated. There is indeed a constant level of complexity, but this is not because complexity is conserved, but because of a kind of homeostasis. As some forms of complexity disappear into the platform, new forms of complexity are continually created. Or rather, we create new forms of complexity for ourselves.

Most people and organizations are permanently operating at levels of complexity at or beyond their ability to manage it. But whenever new technology offers to shoulder some of the burden of complexity, we say thank you very much and immediately take on new and more difficult stuff, thus restoring the status quo.

So I see the job of the technologists (above all the platform designers) differently to Mike and Andy. It is not to reduce the total amount of complexity visible to the end-users, but to increase the end-users' capacity to handle complexity. Doubtless the BI technologies and practices discussed by Mike and Andy can make a useful contribution to this outcome.