Callan Carpenter interview 5 – the 12 month cycle

Callan Carpenter interview 5 – the 12 month cycle

This 5th post concludes the Callan Carpenter interview series. For the record, this interview was done in real time over the phone, with no prior notice of the questions.

SJ: The 12-month cycle that you have for most of your software has come under some criticism from all sorts of people, especially me. Once you have your customer base practically all on Subscription, what’s the incentive for the 12-month cycle to persist?

CC: In what way have you criticised the 12 month cycle?

SJ: In that it damages the product. In that there’s not enough time to release a properly developed product within that 12-month cycle. This is an observation that many people have made going back many years. That’s the basis of the criticism; not that, “Oh no, you’re giving me more software”. Well, there are people who complain about that but I don’t think that’s a valid criticism. I think the valid criticism is that it damages the product. A poll that I ran on my blog asked that question: is the 12-month cycle damaging the product? The answer was a very emphatic yes from the readers of my blog. I know that’s not a scientific survey but it fits in with other viewpoints I’ve seen expressed in various places.

CC: The question was, do we intend to continue to do that?

SJ: Yes. Once you have effectively have your customers on the Subscription model, so that you’re no longer internally competing with the upgrade model, do you really have to have a 12-month release cycle?

CC: Well, I think it’s a very interesting and valid question, do we need to have a 12-month upgrade cycle? I know there are customers who simply cannot absorb technology at that rate. But it’s a bit of a two-edged sword, in that if we go to a 24-month cycle, for example, do we get criticism for not providing enough value for the Subscription dollar or is it going to be viewed as a positive because it’s improved overall software quality? If we stay at the 12 months, we get the reverse argument. Maybe we’re providing the value that customers are paying for with Subscription, but what are we doing to software quality? I think that one of the things we have to look at over time is alternative delivery mechanisms. You’re going to start to see, for example, software delivered (as we have started to) with things available as Software as a Service. That obviates a lot of the issues associated with those release cycles you’re talking about. Your quality can go up, it’s a lot more controlled environment, and the customer doesn’t have to deal with an install, then another install and another install. So I would imagine you would see augmentation of our desktop products with products like that, that sort of move away from the complexities of the constant need to try and absorb new technology.

I think that it would be a very interesting thing to do on a scientific basis to understand whether customers prefer us to go a 24-month or an 18-month, or you-pick-the cycle. I think internally, your question about is it motivated by some kind of internal competition with upgrades, absolutely not. Upgrades, just look at the numbers, that battle’s over, so there’s no internal competition in that regard. The thing that we do have to deal with, which I think is endemic to any engineering creative group, is software engineers like to write software. They’re not motivated by issues of Subscription, or upgrade, or anything else. What they do is create product. We would literally have to rein those guys back if we wanted to go to a longer cycle. They’re the ones leading the charge on that, not the Subscription program.

SJ: So you’re saying that the development teams like the 12-month cycle?

CC: They do. It brings a certain discipline to them on the one hand; on the other hand, it’s kind of what software writers do, they write software.

SJ: Right, but they can write software that takes 12 months and isn’t finished or they can write software that takes 18 months and is finished. If I were a developer I know which I’d prefer.

CC: I hear your point. I think something we have to always look at is what’s the right balance between functionality and trying to build a bridge too far and to get it released. That’s something I know the product division managers are looking at constantly. Again, it’s absolutely not motivated by Subscription. Like you, I’ve heard customers say, “Would you go to 24 months?”, so I’d be happy to deliver that for them in some cases. But it’s really up to the product divisions.

See also
Callan Carpenter interview 1 – Autodesk and social media
Callan Carpenter interview 2 – upgrades a tiny minority
Callan Carpenter interview 3 – the cost of complexity
Callan Carpenter interview 4 – enhancing the program

2 Comments

  1. “The thing that we do have to deal with, which I think is endemic to any engineering creative group, is software engineers like to write software. They’re not motivated by issues of Subscription, or upgrade, or anything else. What they do is create product.” — Very true!

    “We would literally have to rein those guys back if we wanted to go to a longer cycle. They’re the ones leading the charge on that, not the Subscription program.” — Totally false!

    As I stated in Part 2 of this interview series — http://goo.gl/gOBt — The “Subscription” option was not made on software engineering decisions, it was made on finical business decisions. For “Subscription” to work, a 12 month release cycle was forced into a square hole…

  2. I saw 12, 18, and 24 month release cycles mentioned. What about longer? What was wrong with the gap between R13 and R14? 28 months, and R14 is still considered to be one of the better releases, solid for 25 months itself until 2000 came out. IIRC, 14.01 was the only “patch” released, and that was just to include VBA..?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.