Autodesk Responds to the PolyFace Mesh Issue

Kean Walmsley, Senior Manager – Developer Technical Services or Autodesk responded to my post about the PolyFace Mesh issue. This is what he said:

Deelip,

A little on how this works from Autodesk’s side of things. I’ll let you decide whether you “lost on votes” or not.

My team (Developer Technical Services – the staff providing the various technical services via ADN) receives bug reports and enhancement requests from ADN members, which we then validate and submit to our various engineering teams.

Once we’ve logged a Change Request (CR) in our CRM system, we report back to the person submitting the issue with an ID that can be used in future to refer to that CR. We also make sure we ask the person submitting the issue to justify the priority of the issue, so that we can help prioritise dealing with it.

That’s our standard procedure… now for how timing can affect things.

You submitted this particular limitation in early December 2006. Now of course you’re going to say “but that’s given you two years to deal with this!”, but let me explain why this unfortunately isn’t quite how it works from our side. You submitted the issue at what was unfortunately a very late stage of our development cycle for AutoCAD 2008, and without some justification of external urgency/priority, we didn’t have much choice but to defer the handling of the issue for that release. Early on in the development cycle we are much more open to such requests, but as the cycle proceeds we get very conservative – which I know can feel frustrating, but is also a pragmatic approach for maintaining the quality of the AutoCAD product/platform.

OK, your next question is probably “so why wasn’t this carried over automatically for handling in the next release?” Once the CR is in the system and gets deferred for a particular release, we wait for one of two events to occur: either the developer submitting the issue gets back to us with a “business case” so that we can help engineering decide where to prioritise, or we have other developers submit the same issue, which then get linked into the same CR and cause us to ask engineering to take another look into it. In this case we unfortunately received neither a further justification from your side for making the change nor any subsequent report from a developer complaining about the issue.

When I say a business case, here’s what we actually asked for in our email to you:

“If you would like to provide a business case towards implementing this Change Request, please append it to this current case and we will forward it to our development team. Your providing a business case can increase the urgency of your request with our engineering team. Please provide as much information as possible, including the impact of this issue on your application, the number of users affected, and the expected revenue impact for both you and Autodesk. “

To be clear about this… we don’t necessarily need a lengthy, detailed or even a financially impressive justification for us to prioritise handling an issue, but we do need to hear from someone (whether you or someone else) that this issue is worthy of resource investment. If we had received some kind of justification, even something like “as models gets bigger, it’s going to be increasingly important for customers to deal with huge meshes”, then that would probably have been enough to at least have someone from engineering evaluate the amount of work required to address this.

So, a couple of suggestions for getting changes made to Autodesk software: firstly, always let us know when an issue is important to you. I know that might sound silly, but when you have software that is used by millions of end-users with a development community numbering in the thousands of companies, squeaky wheels get more attention. So be vocal.

Also, keep track of your pending CR IDs and don’t be shy about sending them into my team to get status updates (and to give us a prod). We can tell you whether issues are basically in a holding pattern (i.e. a black hole) or whether something is likely to happen. As a matter of course my team now sends status updates to developers when the status of their issues changes, but that’s only a process we’ve had in place for a year or two (and issues submitted prior to that won’t be covered).

I hope this helps explain some of what went on behind the handling of this issue.

Kean Walmsley

Senior Manager
Developer Technical Services
Autodesk

I appreciate Kean’s reply, which has given me (and probably you as well) a deeper insight as to how things happen in a company as large as Autodesk.

The Autodesk approach seems to be reasonable, but I find a fundamental flaw in the logic they employ. Before I delve deeper, I would like to say that the approach being discussed here pertains to the manner in which Autodesk handles Change Requests from its developer partners, which may be very different from how they handle requests from end users.

As I see it there are two kinds of Change Requests – those that help the developer and those that help Autodesk. Lets keep customers out of this for the moment. I think this whole idea of a developer being asked to submit a business case make sense only when the requested change is going to primarily help the developer. For example, suppose a developer wants Autodesk to add mesh boolean functionality to AutoCAD because a plug-in that he is developing needs it. In such a case, Autodesk is perfectly justified in requesting the developer to submit a business case for Engineering to review and decide whether it is worth making the change. But if a developer calls attention to a fundamental flaw and limitation of AutoCAD, in this case, something as serious as invisible and unselectable geometry and something which even AutoCAD’s own Audit command cannot fix, I do not see the sense in asking the developer to provide a business case. Its like Obama asking the CIA to convince him that Osama with a nuke is a bad idea.

Recently, when it came to my notice that Autodesk had still not fixed the PolyFace Mesh, I brought it up with them and rightly enough, according to the system they have in place, they asked me to provide a business case. I am a software developer and whenever someone finds a bug with my software I thank him from the bottom of my heart, go ahead and fix the problem, let him know when it is fixed and thank him once again for helping me improve my software. So when Autodesk asked me for a business case to convince them why AutoCAD should be able to handle large meshes or why it should not have invisible and unseletable geometry, it ticked me off. This is part of an email I sent them:

“You have to be kidding me. As a well meaning and concerned partner I have done my part in pointing out the problem. I have done my part in suggesting a solution and now I have done my part in reminding you to solve the problem. I do not have the time nor the patience to create a business case that explains common sense.”

Subsequently, after being told that, as a rule, Engineering would not consider any Change Request unless there is a business case attached to it or unless it was a stop ship issue (crash), I did supply a business case. Armed with my business case, my contact at Autodesk tried his best to convince Engineering, but it was too late. The new DWG format was already locked by then and changing it would mean conducting extensive regressing testing which would throw everything off track.

I still think I lost on votes. If more people had made a noise about this issue, it would have been noticed and I would not have been writing this. But after reading Kean’s reply, I have also come to realize that I made the mistake of assuming that someone at Autodesk would see the sense in my request and fix the problem. But their system is not designed that way and I sincerely hope that they do something about it.

I have learned my lesson. The next time I submit a change request to Autodesk I know exactly what to do.