What is Technology Maturity?

@madgreek65 asks whether cloud computing is "mature", and whether it matters (What the masses are missing about the cloud).

I suggest that there are several characteristic features of a technology or product, indicating whether it is mature or immature.

	Immature	Mature
Product Stability	Subject to frequent and significant improvements. In a state of "permanent beta".	Stable. New releases are fairly predictable upgrades.
Conceptual Stability	Terminological disputes. Disagreements as to what the technology is "all about".	Terminology "taken for granted".
Technology-in-use	A small number of early adopters trying ambitious stuff. Little consensus about how the technology should be deployed and used.	A large user community doing similar stuff. Use of the technology has become standardized "best practice".
Growth	Large untapped market. Rapid growth possible, under favourable conditions.	Relatively little scope for further growth.
Metrics	Absent or unreliable	Systematized
Adoption Risk	High	Low
Adoption Benefits	Potentially high	Moderate

This notion of technological maturity has the following consequences.

1. It is unrelated to quality or value. A mature technology or product can be unimaginative, boring, almost obsolescent, whereas an immature technology can be visionary, exciting in conception and engineered to the highest standards.

2. Maturity is as much to do with the community of users (technology-in-use) as about the designed products (technology-as-built).

3. The adoption roadmap for an immature technology may be rather complicated. One of the main reasons for this is that the adoption programme needs to bridge the gap between technology-as-built and technology-in-use. There is also a common preference for a cautious stepwise approach - pilot projects, proof of concept and so on. But the stakes can be much higher.

As Mike points out, for any technology that is in the hype phase, there is a lot of resistance to change, and this is certainly true for cloud computing. Mike suggests that a lower-risk adoption approach will win over the sceptical.

"The reason why I encourage those who are pessimistic about the cloud to try one of these low risk scenarios is once they see how easy it is, how productive they can be, and how inexpensive the project will be, then maybe they will see the value and investigate further."

For many people, this is the preferred approach for an immature technology. However, there are some specific risks associated with a slow adoption curve, which I shall discuss in a future post.

---

See also previous post: CEP and technological maturity

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

Blame Excel

@thinkovation (Gary Barnet) argues that the current financial crisis was caused by Excel (via @neilwd).

@monkchips thinks this is silly. I think he means it is silly to blame things on Excel. Of course Gary make it clear that he is actually blaming things on people using Excel stupidly.

If it is silly to blame a lump of software when things go wrong, it is equally silly to credit a lump of software when things go right. But this is exactly what the software vendors do all the time - claiming all sorts of benefits from the use of their products.

@jevdemon adds: "bad carpenters blame their tools". And good carpenters never praise their tools.

There are some fundamental logical flaws in the way people commonly reason about lumps of software as instruments - means to producing some end. See my paper Reasoning about Systems and their Properties.

See also my post A Better Instrument?

And for a related point, see Mike Kavis, When in doubt, blame the cloud