Responses to the Threading Maturity Model

January’s proposal of a Threading Maturity Model (ThMM), both in my blog and in SD Times, has inspired some thought-provoking conversations. So far, nobody has proposed any changes to the model. I’ve been impressed by several writings that comment or expand on the ThMM, which ranks an organization’s or team’s threading skills and practices.

First, my colleague (and SD Times columnist) Larry O’Brien has proposed a complementary Personal Threading Maturity Model (PTMM), a five-point scale ranking individual progress toward mastery of threading. “An organizational model is necessary because, as with object orientation, it does not suffice for a single person to have mastery or near-mastery; the average ability of the team must be at least fair in order to maintain quality,” he writes.

Michael Suess writes, in his blog entry Parallel Programming is Entering the Mainstream – or isn’t it?, that “Alan Zeichick is convinced that parallel programming (threading in this case) is conquering the desktop.” Well, that’s not quite what I said or meant; the ThMM isn’t focused on the desktop, and the goal is to measure competency, not predict market penetration. Beyond that, he makes some excellent observations: “Refactoring a big, existing codebase to use threads or some other parallel programming model is a huge undertaking (sometimes even comparable to a total rewrite)…. If, on the other hand, the technical leadership of a software shop acknowledges the risk and decides to act in anticipation of the problem, a migration may be started early and will go more smoothly because there is more time to get everything right.”

Rob McCammon goes farther, talking about developing a multi-core readiness plan for embedded projects. “This is why I believe that any development team that sees a transition from a single processor to a multi-core processor on the horizon must develop a multi-core readiness plan. Not doing so is like mounting an expedition to Mount Everest by simply making your way to base camp and trying to figure it out as you go from that point forward,” he says.

Michael Cassens suggests in his blog that “the average lifespan of a new consumer computer is 3-5 years. This means that within the next year or two, most computers will have at least a dual core system inside. I think consumers will continue to demand more responsive software and their data needs are only going to grow. I think that all developers will have to be at a high level of adoption in the next few years or they will be left behind.” Further, he adds, “The article suggested that most corporations are in Tier 1 or 2 at the moment. There is definitely an interest in parallel programming, but dual core and quad core systems are going to force developers go beyond just hobby programming and integrate these solutions in their production level applications.” I agree completely.

David Dossot goes in a similar direction as Larry with his Threader Maturity Model, which also focuses on individuals, not organizations. It’s interesting to compare and contrast their different five-step scales. I like his fifth level: “Adoption. This is also known as Being Brian Goetz. At this level, the developer has an intimate knowledge of the memory model, the concurrency mechanisms and all that pesky internal details. He is able to think in all the dimensions of multi-threaded development (time, space and whatnot). Nirvana is nearby.” Brian Goetz is an extremely well-respected Java guru, and his newly published Java Concurrency in Practice is outstanding.