Tag Archives: 12-Month Release Cycle

33 years of AutoCAD upgrades rated – part 5 – summary

13 Replies

In this final post of the series, I’ll examine the patterns that have emerged from the upgrade history I rated in parts 1 to 4. Bear in mind I’m only assessing the DOS (up to R13) and Windows (from R12 on) versions of the full version of AutoCAD. Of course, this only represents my opinion of those releases and is bound to be biased by the uses I and my users have for the software. Your experiences and opinions will almost certainly vary.

What can I say? My assessment is based on a third of a century of experience, and I’ve tried to be as objective as I can. I’m not unique in perceiving the decline of the AutoCAD upgrade; you’ll see the same said by long-standing customers and experienced independents all over the place. Ralph Grabowski, for example:

The new feature list for AutoCAD’s annual “big-R” release has become so short that I stopped producing my annual “What’s Inside? AutoCAD” ebook series in 2013.

 
Back to my own assessment, here’s a graph that shows how I rated the releases:

One thing’s obvious and that’s the permanent drop in the rate of improvement that set in with the onset of the annual release cycle. My average rating for AutoCAD Version 2.0 to 2000 is 7.7. For 2000i to 2017, it’s 3.4. Autodesk switched to doing half as much worthwhile development between releases, but charged the same upgrade fee. Value for money halved.

We entered the era of an endless stream of annual releases with fewer genuinely useful new features. Worse, the abbreviated cycle meant most of those features went into production half-baked in design, implementation or both. Some of those undercooked features (the lucky ones) got some attention in the next release. Many more of them never got fixed, or got quietly removed later, or eventually got patched up years after the user base had ignored them to death.

Have a look at the decline from 2010 downwards. The average for the last five releases is 2.0. The rate of improvement per release, starting from a low point, took a nose dive. Value for money, which was poor, is now dire.

Conclusion? AutoCAD is in maintenance mode. Autodesk’s attention (and investment) is elsewhere and it is just going through the motions of updating the software. Progress has stalled. Inspiration is AWOL.

Nevertheless, through all this, we have still paid for new releases in various ways, and in huge numbers. No wonder Autodesk is convinced we’ll be silly enough to pay over the odds to rent software; there’s a precedent.

The more Autodesk has moved away from the optional upgrade model, through optional maintenance*, then effectively compulsory maintenance**, then finally to the compulsory rental model***, the weaker the upgrades have become. Autodesk no longer feels compelled to put in the development effort that will convince customers to shell out for the advantages provided by a new release.

Autodesk wants an endless revenue stream in return for merely providing access to the software, rather than as a reward for improving it: money for nothing. That’s Autodesk’s dream, and an understandable one. For customers, it’s a nightmare: nothing for money.

Part 1 – AutoCAD Version 1.4 to Release 11.
Part 2 – AutoCAD Release 12 to AutoCAD 2002.
Part 3 – AutoCAD 2004 to AutoCAD 2010.
Part 4 – AutoCAD 2011 to AutoCAD 2017.
Part 5 – Summary.

* Maintenance was previously called VIP and then Subscription.
** Autodesk restricted the availability of upgrades, priced it out of the market, and in some cases only sold perpetual licenses bundled with maintenance, before finally eliminating upgrades altogether.
*** Autodesk’s third attempt at rental (there were failed attempts in 2001 and 2013) was first called Desktop Subscription and then just subscription. I generally call it rental to avoid confusion with The Maintenance Formerly Known as Subscription.

I was wrong about AutoCAD 2013 Help, it still sucks

8 Replies

In my effusive welcome of AutoCAD 2013’s updated Help system, I wondered if I had been shocked into missing some glaring problem. Unfortunately, that’s exactly what happened. In my enthusiasm, I managed to totally miss the fact that the new system has not been introduced for offline users.

If you use the new system, there’s a link on the front page to the offline files. I got as far as downloading and installing what I thought was the offline version of the new system and discovered that it didn’t want to install because the old one was already installed. What I should have then done, and didn’t, was to uninstall the old and install the new, before running it in offline mode. I intended to get around to that to check the performance and responsiveness of the respective versions, but didn’t have the time right then. If I had done so, I would have noticed that my download, uninstall and reinstall would have been in vain, because the offline version pointed to by the new system is still the old version. My apologies to anybody who wasted their time because of what I originally wrote.

There are many legitimate reasons why Autodesk customers want or need to use their software, including the documentation, entirely in offline mode. For example, the users I manage can’t access the online Help system from AutoCAD because Autodesk writes its software in such a way as to fail in a secure proxy server environment (yes, this has been reported as a bug, repeatedly). So for my users and many others, it’s true to say that despite the best efforts of Dieter and his team, AutoCAD 2013’s Help still sucks.

Look at this from the point of view of such offline AutoCAD 2013 Help users. We pay large amounts of money for software and Subscription. No “entitled” 99-cent users here.  We’ve provided extensive feedback on the woeful system that was inflicted on us at release time. We’ve hung out for half a release cycle with no adequate stopgap, even though one could easily have been provided. A small team has finally wrought an outstanding improvement and deserves congratulations for doing so. The improved system is dangled in front of our faces, and then we discover that we’re not allowed to have it. Not for any plausible technical or resourcing reason, but because Autodesk simply doesn’t want us to have it. How are we supposed to feel about that?

That’s right. Autodesk has managed to snatch a crushing defeat from the jaws of what should have been a stunning victory. I guess I should have expected something like this; for Autodesk, the half-baked job is de rigeur. But this goes beyond the usual problem of countless features that would have been great if they had been finished. This isn’t a matter of a product team struggling to develop features adequately within an impossible timeframe imposed by the yearly release cycle. This is a matter of policy. Some Pointy Haired Boss at Autodesk has decided to deliberately disenfranchise a significant group of its paying customers, by refusing to make available something that already exists and could easily be provided. This adds insult to the injury of having to wait 6 months for a CHM stopgap that was clearly the right thing to do, but which never came.

Why? What on earth would lead anyone to even contemplate the possibility that this might be a good idea? Lack of resources? While I’m quite aware that individual parts of Autodesk have their own budgets and limited resources, I don’t buy that as an excuse for the organisation as a whole. A multi-billion-dollar corporation that pays its executives millions? One that just threw away $60M on a dud social media buyout? Crying poor over something that would have cost maybe a few thousand? Sure, sounds legit.

No, a lack of resources is not the reason. It’s a policy issue. “There’s no reason for it, it’s just policy.”  But why would such an anti-customer policy exist? Vision. Autodesk is currently led by a Cloudy Vision. It’s important to Autodesk that everything Cloudy looks good. It’s clearly not enough to actually make online stuff work well. For one thing, that’s obviously pretty difficult, judging from Autodesk’s offerings to date. No, anything that’s offline has to be made to work badly, so the comparison looks as favourable as it possibly can. That’s much easier to arrange.

That’s why there was no CHM solution on the release date, despite Autodesk having a set of unpaid volunteers ready to put the thing together. That’s why there was no CHM solution provided a week later, or a month later, or six months later. Don’t think that it wasn’t provided because of a lack of resources; that excuse is entirely specious. It wasn’t provided because it would have made the online version look bad in comparison. The online version already looked abysmal, but an offline CHM solution would have just made the comparison so ridiculously one-sided that nobody would have been in any doubt about what a terrible idea on-line Help was. The Cloudy Vision would have looked suspect at best, and we can’t have that, can we?

What Autodesk wants is for people to think “Cloud good, non-Cloud bad”. If the Cloud can’t be made good, then making non-Cloud bad will have to act as substitute. Loading the dice in this way might stand a chance of working if customers were as clueless as some Autodesk decision-makers, but most of us aren’t total idiots. We notice these things.

This is a line-in-the-sand issue. This is about Autodesk pushing its vision at the expense of customers. No news there then, but from my point of view, this is one step too far. This is the tipping point where the not-convinced-about-the-Cloud phase could well turn into a full-scale take-your-Cloud-and-shove-it customer revolt. Me? I’m quite prepared to hand out the pitchforks and torches.

Carl of Arc

Source images: Hermann Anton (public domain) / Carl Bass (creative commons)

Carl Bass, you need to pull your troops into line. Let them know that while your Vision is important, implementing it must never come at the expense of common sense. It must definitely, never, ever come at the expense of your customers’ needs.  Blindly following a Cloudy Vision didn’t end well for Joan of Arc, and it’s unlikely to end well for Autodesk either. Please remember the source of Autodesk’s income. Without customers, you are nothing. You are treating your customers badly, and worse, treating us as idiots. Please, give it up before we give you up.

AutoCAD 2012 – Array has good and bad points

19 Replies

For many users, the most useful new feature in AutoCAD 2012 is going to be the updated Array command. It adds a great deal of very welcome new functionality that will provide a potential productivity boost for 2D and 3D users. But it’s from an Autodesk wedded to its infernal 12-month product cycle, so of course it’s half-baked.

The Good

So what’s good about the Array command in AutoCAD 2012?

  • Associativity. By default, arrays are now associative objects. This means that if you want to, say, modify the distance between columns a couple of days after you drew them, you can now do so. If you’re a Ribbon user, it’s easy to change array parameters because when you select an array, you get a Ribbon tab dedicated to just that task. If you’re not, then the Properties palette allows you to do the same thing.
  • Dynamic preview. Once you have set your various options appropriately, you can just move your cursor around and click to choose things like the number of rows and columns.
  • Path option. In addition to rectangular and polar arrays, you can now array along a path such as a polyline, similar to the Measure and Divide commands. But because it’s associative, if you edit the path, the array changes too.
  • 3D functionality. It is now easy to create 2D or 3D arrays with the Array command. You can add levels (Z) to the rows (Y) and columns (X) of arrays, and this applies to all three types of array. You can also provide a elevation increment, which means the items get progressively higher the further they are from the base row. Think of the seating in a stadium as an example, although real seating arrangements are usually more complex than you will see in the Autodesk examples, so in the real world I don’t expect this feature to be used much.

The Bad

So far so good, then. But what’s not so good?

  • 1990s user interface. Can you remember when the Array command had only a command-line interface? Because that’s what it has now. While some of us old-timers may yearn for some aspects of the “good old days” of 1997’s Release 14, I don’t think many of us want to lose truly useful functionality. But that’s what has happened here. The Array command uses the new command line. The -Array command uses the old command line. Nothing uses a dialog box; there’s no ClassicArray command. *
  • Bugs and limitations. The new command line interface ain’t cooked. There are a bunch of bugs and limitations that mean some valid inputs get rejected, some arrays get drawn incorrectly, and some can’t be created at all. There are other aspects of the feature that strike me as not well thought out, such as the extra step involved in creating a non-associative array (not everybody will need or want associativity), or the clumsy way in which users who want to keep existing objects are expected to mess about with a system variable that affects unrelated things. **
  • Missing API. Autodesk’s long-standing grotesque neglect of LISP continues with the new Array object. There is no meaningful ActiveX API for such objects. If you wanted to use ActiveX to create a simple array, you would have to pretty much reproduce Autodesk’s array creation code (it’s an anonymous block, really) and hope you got it right. There is, of course, no documentation whatsoever to help you do this.

On balance, the AutoCAD 2012 Array command should be viewed as a positive, but it could (and should) have been done a lot better.

* Disclaimer: I have written my own ClassicArray™ command, and I intend to provide it as an add-on soon. Watch this space over the next few days for a public Beta. Edit: here it is.

** ClassicArray acts as a workaround for many of these bugs, limitations and design failings.

Why we keep upgrading

2 Replies

In a comment in response to a Deelip post yesterday, Brad Holtz pointed to an article he wrote in 1999. It’s interesting to note that while much of the computing world today bears little resemblance to the scene at the end of the last century, this article remains almost completely accurate and relevant. Indeed, it’s so right that you might even be tempted to think, “Duh, isn’t that obvious?”

One section that stood out to me had this to say:

Many software systems never even get beyond the acceptable stage …. vendors of these systems are continually coming out with new versions, never stopping long enough to fix the problems with the existing systems.

It’s fascinating to me that this observation came at the very time that Autodesk was switching from a company that wasn’t exactly like that to one that very much was (and still is today), thanks to the 12-month release cycle.

Raster Design 2011 due out on 20 July?

Leave a reply

After an interminable delay and a complete absence of information from Autodesk (no, “contact your reseller” doesn’t count, especially when they don’t know anything either), it seems Raster Design 2011 is going to be released on 20 July. If that’s correct, those of you who use, say, image formats not directly supported by AutoCAD (e.g. ECW, MrSID) are finally going to be able to start using AutoCAD 2011, “only” 117 days after its release.

Don’t worry, I’m sure Autodesk will be refunding 1/3 of this year’s Subscription fees for both products. (Yes, that’s a joke).

I only hope the delay has given Autodesk enough time to fully fix the network/standalone SNAFU that blighted the Raster Design 2010 release. It’s still broken for users of network AutoCAD 2010 (or related vertical) and standalone Raster Design 2010. As there appears to be nothing new in the product except Windows 7 and 2011 support, and 2011 support should have been very easy to add, what else could Autodesk have spent all this time doing? Unless it’s related to this law suit?

While this unannounced delay isn’t much of an advertisement for the 12-month release cycle, it does indicate the need to keep the release dates for AutoCAD and its related products closely aligned, regardless of the cycle length.

Disclaimer: it should go without saying, but just in case anyone’s wondering, none of the content of this post is based on privileged information. My source is this document (181 KB PDF), mentioned in this thread.

Callan Carpenter interview 5 – the 12 month cycle

2 Replies

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

AutoCAD 2011 Help system is not popular

9 Replies

My poll on this subject is still running (see right), but so far about 2/3 of respondents rate AutoCAD 2011’s new browser-based Help system as 0, 1 or 2 stars out of 5 (total fail, very poor or poor). Frankly, I’m surprised it’s doing as well as that. Have a look at this discussion group thread to get an idea of the sort of reaction I was expecting it to receive. (Kudos to Autodesk’s moderators for allowing the discussion to continue with relatively little obvious censorship, at least so far).

There are many good new things in AutoCAD 2011, but Help isn’t one of them. Even if you like the concept of online help, this implementation of that concept is a failure. Even when used offline, this release’s browser-based Help is manifestly inferior to its CHM-based predecessor. Yet another victim of the 12-month release cycle, this feature is horribly undercooked and should not have been included in the finished product. As an advertisment for Autodesk’s ability to provide efficient cloud-based and/or platform-independent software, it could hardly be worse.

I intend to pull Help to shreds in more detail in a later post, but feel free to add your own observations.

The 12-month cycle and shipping software with known bugs

9 Replies

In a recent blog post, Deelip Menezes appears to be shocked by the very idea that a particular CAD company (no, not Autodesk) would ship software that contains known bugs. I thought he was joking, because he’s surely aware that practically all software companies with highly complex products release software with known bugs. As Deelip points out, those companies with 12-month cycles are particularly prone to doing this. There is no possible way any company can release something as complex as a CAD application within a fixed 12-month cycle without it containing dozens* of known bugs (because there isn’t time to fix them after discovery) and dozens* of unknown ones (because of insufficient Beta testing time).

Reading Deelip’s post and subsequent comments more carefully, it becomes clear that he doesn’t mean what a casual glance might lead you to believe he means. Deelip makes a specific distinction between “bugs” and “known issues”. He states that if a bug is discovered and the software is then adjusted such that it does not abort the software in a badly-behaved way, and this is then documented, then the bug ceases to be a bug and becomes a “known issue”.

I disagree. Bugs can cause crashes or not; they can cause “nice” crashes or not; they can be known about prior to release or not; they can be documented internally or not; they can be documented publicly or not. As far as I’m concerned, if the software doesn’t act “as designed” or “as intended”, then that’s a bug. Here’s what Wikipedia has to say, and I concur:

A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect or unexpected result).

That doesn’t mean that software that is “as designed” (free of bugs) is free of defects. Defects are things that make the software work in a way other than “as it should”. They can be bugs, design errors or omissions, performance problems, user interface logic failures, API holes, feature changes or removals with unintended undesirable consequences, and so on. Unfortunately, defining “as it should” isn’t a precise science. You can’t just compare the software to the documentation and say that the differences are defects. The documentation could be faulty or incomplete, or it could perfectly describe the deeply flawed way in which the software works.

While I disagree with Deelip’s definition of bugs, I couldn’t agree more with a more important point he makes in his blog post. That point is of a fixed 12-month cycle being the root cause of a plethora of bugs/issues/whatever making it into shipping software, and this being an unacceptable situation. This is a view I expressed in Cadalyst before I started participating in Autodesk’s sadly defunct MyFeedback program, and it’s a view I hold even more strongly today.

In conclusion, I would have to say that the fixed yearly release schedule is not good for AutoCAD. It is good for Autodesk, certainly in the short term, but that’s not at all the same thing as being good for AutoCAD or its users.

I’m not alone in thinking this. The polls I’ve run on this subject, discussions with many individuals on-line and in person, and many comments here and elsewhere, indicate that a dislike of the 12-month cycle is the majority viewpoint. For example, when asked the question, “Do you think the 12-month release cycle is harming the quality of AutoCAD and its variants?”, 85% of poll respondents here answered “Definitely” or “Probably”. In another poll, 71% of respondents indicated a preference for AutoCAD release cycles of 24 months or greater.

Somebody please tell me I’m wrong here. Somebody tell me that I’ve misread things, that customers really think the 12-month cycle is great, and that it’s not actually harmful for the product. Anyone?

* Or hundreds. Or thousands.

Autodesk’s Revit rebellion reaction

11 Replies

It’s time to examine how Autodesk has reacted to the widespread criticism of Revit 2010. Is Autodesk listening? To be more specific, is Autodesk’s Revit team listening?

The Good

It has been good to see extensive public participation by Autodesk people in various discussions in different places. The Revit team isn’t hiding. It is asking for feedback on the Autodesk discussion groups, the AUGI forums and its own blogs, and getting lots of it. Much of it is negative, but it is to Autodesk’s credit that I’m not seeing much in the way of denial, or demands that the criticism must be constructive. I’ve been trying in vain for years to convince some people at Autodesk that denial is counterproductive and that criticism doesn’t have to be constructive to be useful.

The sort of messenger-shooting that I’ve seen some Autodesk people do from time to over the years (*cough* R13, CUI *cough*) is generally absent. I’m not seeing Adeskers arrogantly accusing users of their criticism being based on a failure to understand the product. I’m not seeing asinine comments that infer that the negativity is simply a symptom of the critics’ resistance to change. Actually, I’ve seen one such comment, but it wasn’t from an Autodesk person.

Overall, the Revit team’s responsiveness, openness and level of public availability is impressive. It’s so good that it puts other Autodesk teams to shame. When was the last time you saw an Autodesk person respond to criticism of AutoCAD in the Autodesk discussion groups or AUGI forums? Revit people are doing quite a bit of it, and by looking back I can see that they have been doing it for a while.

There was one attempt at a traditional corporate “the product is great, we just need to review our communications” message. Unsurprisingly, it didn’t work (read the comments). Denial, spin, obfuscation; these things never convince the people who need to be convinced, so why bother? While it’s good to see a reaction from somebody pretty high up in the chain of command, the people lower down have been doing a much better job of communicating with their customers.

The Bad

The trouble with all this communication is that it’s a couple of years too late. It’s no good putting a huge amount of effort into something, introducing it to users, then discovering too late that the users hate it. No amount of communication after the fact can make up for that kind of blunder. Exposing an early design to a handful of people in restricted circumstances can be useful, but it’s nowhere near enough. Lots of people need to be exposed to a product for a long time (as the Revit team now acknowledges – see an interesting Autodesk blog post here). The earlier it’s done, the better the product will be. As a bonus in these difficult times, this will lower the overall cost of development, because problems get exponentially more expensive to correct as the development cycle progresses.

From the public comments I’ve read, the Revit Ribbon was presented to beta testers as late as January, and by then it was very much a fait accompli. There was little chance of making it work significantly better, and none whatsoever of removing a bad design from the product before shipping. This scenario is, unfortunately, confined to neither Revit nor this particular instance. Although I can’t comment on my own Autodesk pre-release experiences, if you have read enough public discussions over the years you will undoubtedly have seen this kind of conversation a few times:

Angry user: “This feature is useless! The beta testers must have been blind to miss this!”
Beta tester: “Actually, we did see it and reported it right away. Autodesk just didn’t fix it.”

I would like to expand on this, but I am somewhat restricted by NDA. I’m not complaining about that (it’s a voluntary agreement), just stating the position I’m in.

Another thing that belongs in this category is the Revit team’s apparent disdain for its users’ wishlists. AUGI Revit people are convinced that their wishlists are being ignored, and I can see for myself that Autodesk’s own Revit wishlist discussion group is hardly a hive of activity.

The Ugly

Autodesk showed the cloven hoof with its exclusion of Phil Read from Autodesk University.* This reflects extremely badly on Autodesk. See here, here, here and here. Almost everybody seems to think this crude and futile attempt at censorship was a deplorable move, and I agree. Besides this being an example of messenger-shooting at its worst, it’s not a good look for the AU event itself. When you pay your AU fees, are you hoping to see the most knowledgeable, enthusiastic, passionate and inspiring speakers available? Or just the ones with opinions that align with Autodesk?

* My reaction is based on the assumption that this exclusion did take place. It has been widely reported and condemned, but not denied by Autodesk, so I think it’s a pretty safe bet. The only comment from AU management is, “Speakers for AU 2009 will be announced around June 15 – I cannot comment before.”

Autodesk answers – 1 of 4

16 Replies

At the end of January, I asked for your questions to put to Autodesk product managers. My intention was to pose your questions in a video interview format while attending the AutoCAD 2010 product launch, but for logistical reasons I was unable to make this happen.

Autodesk’s Eric Stover kindly arranged for your questions to be answered anyway. The delay in getting these answers back to you is my responsibility, not Autodesk’s. The answers come courtesy of the following product managers:

  • Diane Li – lead manager on AutoCAD;
  • Guillermo Melantoni – 3D and Parametrics expert;
  • Kathy O’Connell – customer requests, quality improvements, and 2D improvements.

I will post each question and answer a day apart, to give you chance to comment on each issue separately. Here is the first question, courtesy of Chris Cowgill:

Q: With the current release cycle being so short, has anyone considered suspending a new release for a time, to spend an entire release cycle working on improving/restoring functionality of existing features and fixing bugs, why, or why not?

A: With any given release, we aim to deliver a healthy balance of new features & functionality along with improvements to existing functionality, so we can help enable new ways of doing design, but also provide more efficient ways of working the way you do today. We plan to continue this balancing act for future releases, but have also started delivering regular product updates (formerly known as ‘service packs’) throughout the year. So, rather than requiring you to wait for a new release of the product to get product improvements, this year we delivered 3 product updates that included hundreds of bug fixes to existing AutoCAD features and functionality.

AutoCAD 2010 release date

4 Replies

After my recent attendance at the AutoCAD 2010 launch, I have a few dozen subjects I’d like to blog about, lots of video editing to do, and not enough free time in which to do it. Many of my fellow launch-attending bloggers have beaten me to it with many of the meaty bits, but I’ll be covering much of that stuff in my own way and from my own perspective over the next few weeks.

One thing I can do with minimum effort is to pass on an important piece of information I haven’t seen mentioned elsewhere yet: the date that Autodesk plans to actually ship AutoCAD 2010. That date is (drumroll)…

Tuesday, 24 March 2009

No great surprises there; the 12-month release cycle continues as usual.

Although this information was imparted to a room full of bloggers in an on-the-record session, I suspect it may have slipped out accidentally. It’s a planned date and may yet change subject to various circumstances. It applies to AutoCAD and probably AutoCAD LT; the vertical variants of AutoCAD will have later ship dates, probably in mid-April.

Interestingly, in a conversation with an Autodesk Australia person today, I was told that the 2010 launch dates are staggered across the globe. (That’s launch dates, not ship dates). So although everybody in Australia with an Internet connection already knows what’s in AutoCAD 2010, Autodesk Australia itself is apparently not allowed to disclose any information about it until Monday, 23 March 2009. That’s kind of bizarre if true, and I suspect it may be based on some kind of misunderstanding, but that’s what I was told.

How well cooked is the average major new AutoCAD feature these days?

3 Replies

I’ve now closed the poll that asks this question, and the results show a typical bell-curve shape with the peak clearly on “Half-baked”. There is a slight bias to the bottom end, but not a significant one.

This result doesn’t surprise me, as I’ve seen and heard a lot of user comments to that effect, and I’ve made such comments myself.  I’m not saying that this poll is definitive proof of anything, but it sits pretty well with my perception of what AutoCAD users generally think.

Now I’d like you to consider a related question. If we accept for the sake of argument that the average major new AutoCAD feature is half-baked, is that necessarily a bad thing? There are some valid arguments that can be made for pushing out features before they are complete. I’ll examine the pros and cons from my perspective later, but for now I’d like to hear from you.  What do you think?

Ways in which the crash could be good for Autodesk

2 Replies

No, I don’t mean the sort of crash where AutoCAD stops working. The current financial crisis, I mean. I must preface these comments with a disclaimer. I have no qualifications in finance and make no claim of financial expertise. These are purely a layman’s thoughts. Don’t buy or sell stock based on what I have to say here. Toss a coin instead.

So, what on earth am I thinking? I’m thinking that although Autodesk (along with most other companies) will undoubtedly suffer greatly from the coming economic conditions, it’s not all dark cloud. Here are some potential silver linings.

Autodesk is cashed up. If its competitors aren’t all carrying enough fat to survive the lean times, Autodesk could come out of the post-crash period with greater market share than before. Of course, this is contingent on Autodesk having products, customer service and a customer-friendly outlook that are attractive enough to win over any orphans. Some serious reversal of neglect in these areas will be needed, which involves spending more, not less. So it really is a very good thing that Autodesk has large wads of your money lying around for use in times like this.

Companies with useful technology might become available cheaply. Some smart acquisitions could give Autodesk products some advantages over the competition. (Edit – Between writing this post and publishing it, I see Autodesk has just done exactly that with Softimage).

Autodesk can buy its own shares back while they are cheap. If it needs cash in a few years, it can sell them again at what will undoubtedly be much higher prices.

I don’t really care whether Autodesk does any of the above, but I do care about the next one. Autodesk has been living in a Soviet Russia-style fool’s paradise for years with its yearly product cycles. Practically everybody who knows anything about the software knows that the 12-month cycle is unsustainable because of the significant harm that it is inflicting on the products. But it has been an undoubted financial success, so far. Autodesk is addicted to it, but like any unhealthy addiction it will ultimately be fatal. What to do?

This financial crisis represents a get-out-of-jail-free card for the Autodesk board. Announce the long-overdue death of the annual cycle now, while Autodesk shares are already undervalued. Any negative reaction from a share market that doesn’t know or care about product quality will be hard to identify as having a specific cause while the share price is being flushed down the toilet anyway. Announce it in conjunction with something that will save Autodesk money, like abandoning some of its sillier legal adventures, and it will be even harder for shareholders to apportion blame to any particular measure. In a month or two, nobody will be able to identify specific causes of the stock being at whatever level it happens to be at that time.

Such a great opportunity for Autodesk break out of the yearly rut and rescue its products from a sad slide into semi-permanent sub-mediocrity is unlikely to be repeated any time soon. It’s a nettle; it’s going to sting, but it must be grasped.

Can Carl Bass be Autodesk’s Gorbachev?

How long should the AutoCAD release cycle be?

1 Reply

I’ve just added a poll asking this question. Actually, the poll question is rather longer than that, because I want to make it as unambiguous as possible. Other polls I’ve seen on this subject, including ones by Autodesk and Cadalyst, have always left room for speculation about what a given answer would actually mean. Sometimes, the question has been so ambiguous that the results have been completely meaningless. I’ve tried hard to avoid that, and if that means the question is rather long, so be it.

In my poll, you’re being asked to consider a scenario where over a long period of time (10 years, say) the total charge from Autodesk for upgrades or Subscription would be the same, no matter what the release cycle. You would also get the same number of major new features, minor new features and other improvements. Your ability to choose to pay either upgrade fees or annual Subscription payments would also be unaffected. If you feel that you would like to answer “however long it takes to get each release finished” rather than a fixed time between releases, please choose a release cycle period that you think would be a reasonable average. The AutoCAD release cycle would also affect the AutoCAD-based verticals, so please take that into consideration.

I will refrain from giving my own opinions on this subject until the poll is closed, but feel free to make your own comments about the pros and cons of different lengths of release cycle.

Autodesk’s 12-month release cycle – Is it harmful?

16 Replies

I’ve opened a poll asking for your opinion about whether the 12-month release cycle of AutoCAD and its variants is harmful to the quality of the software that Autodesk is providing. I won’t express my own opinion on this subject here yet, but will do so later, once the poll is closed. In the meantime, I’d love to hear your opinions on the subject.

AutoCAD 2009 – Action Recorder needs action

12 Replies

One of the banes of AutoCAD over the past few years is the phenomenon of the half-baked feature. A new feature is added to the product with serious design deficiencies and/or bugs and other shortcomings that make it much less useful than it should have been. I’m sure you have your own favourite examples of this. I may expand on this theme in future, but for now let’s concentrate on one brand new and particularly undercooked feature, the Action Recorder.

The ability to record and play back macros is undoubtedly something that many users want, and has featured prominently in some wishlists. Autodesk has now provided the Action Recorder. Wish granted, right? A shining example of Autodesk listening to its customers and providing what they want and need? Not exactly. In fact, this wish has only been granted at the most superficial level.

Here is the wish as seen on the 2003 AUGI Top Ten AutoCAD Wish List (it’s number 6): “Provide a VBA Macro recorder.” Here it is as it appeared in the February 2006 AUGI Wishlist (it’s number 1): “The ability to record the process of a certain task and assign a quick key to it – similar to Microsoft’s macro recorder for office products.”

People were asking for something similar to what they had in Microsoft products. That is, something that not only allows actions to be recorded and played back, but to also create some kind of editable programming language code. Why would people want that? Because recorded macros can be easily examined, modified, combined, changed from one-off to repeating sequences, used as the basis for slightly different routines without requiring re-recording, incorporated into full-blown routines, and so on. The need for editable code is blindingly obvious, really.

So, how does Action Recorder store its macros? As VBA code? No, but that’s not surprising because Microsoft has dictated that VBA is doomed. LISP code, then? No, LISP is unfashionable at Autodesk. Script files? Nope. XML? Try again. It’s a new and proprietary format. It’s binary, not text. It’s undocumented. There is no known access to the code via AutoCAD’s other programming interfaces. In summary, it’s a closed format.

Does that matter if you can edit it using Autodesk’s tools? Yes it does, but in any case you can’t edit it in any meaningful sense. The only editing mechanism provided by Autodesk is the Action Tree, and it’s woeful. Pretty much the only things you can do with it are to delete whole commands and to change certain recorded actions to prompt for user input instead. You want to change a macro to set up certain layers before you start? Sorry. You want to add a command to the end of a macro? Nope. You’ve picked 3 times during a command and you want to change it to 2 or 4 times instead? Too bad. You want to use one macro as the basis for a whole series of macros, just changing a couple of things from macro to macro? No can do.

This lack of a useful editor isn’t just a problem for CAD Managers and power users. If anything, it’s even more of a hindrance for the novice users it’s obviously aimed at. Who is more likely to get an extended command sequence wrong? A power user with years of experience writing menu macros, or a new user? So who is most likely to need to fix up their macros after recording?

There are various other things wrong with the Action Recorder that go to make it a very frustrating tool. The way in which points with object snaps are recorded is unusable. The way in which zooms occur is bound to cause lots of surprises. The inability to record dialogue box operations is going to confuse and frustrate many users. The habit of the Action Tree in always pinning itself in place is annoying. Its inability to resize outside a very limited range is restrictive. The plethora of in-your-face warnings will have you groaning more than Vista’s User Access Control, and don’t think of turning them off in advance, that’s not allowed. Finally, if you’re not a Ribbon user, forget it. While the command line interface allows for recording and playing back macros, there is no way of editing them. So unless you want to do exactly the same thing in exactly the same location in all your drawings, you’re out of luck.

Don’t take my word for it, try it for yourself. Try to make a macro that does something simple but useful like rotating a piece of text about its insertion point, or inserting a block on a line and then trimming the line within the block. By the time you’ve worked out that it can’t be done, you could have learned about menu macros from scratch and written something that actually works, several times over. A word of warning; please make sure you lock up any pets or children before starting this experiment.

The Action Recorder is a “brochure feature” only; it serves as a marketing tool for Autodesk rather than a genuinely useful productivity tool for its customers. This wouldn’t be so bad if it was an isolated case, but it isn’t. Unfortunately, half-baked new features are now the rule rather than the exception.

Why is this so? Is Autodesk cynically trying to fool its customers in an evil revenue grab? Does the AutoCAD development team spend its time trying to come up with deliberately half-baked features? No. The developers don’t want to make these weak and useless things; they are human beings with the same urge as the rest of us to do well and be proud of their work. The problem is that there is simply not enough time to do a good job with a major feature and finish it off. It all comes down to the 12-month release cycle; it just isn’t working.