Deelip.com

Saturday, June 13, 2009

User and Non-Users

In a comment, Matt Lombard asked me to comment on something that I have been trying to avoid talking about for quite some time. He asked:

"To the best of my very poor memory, all of the proponents of Direct Editing as the New World Order for CAD are non-users, and the proponents of history are users ...[snip]... Any comments on that?"

If you are a so called user, please forgive me if you find some of what you are about to read offending. It is not my intention to offend anyone. Definitely not Matt whose blog, I believe, is one of the best CAD blogs out there, not just for the content, but also for the way he puts it.

I want to keep Direct Modeling out of this discussion and only talk about this concept of users and non-users that Matt brought up. Over the years I have been reading comments from users which imply that the CAD media, analysts, authors, etc. have their heads in the clouds and do not know what they are talking about because they do not do real modeling work. I have even heard pretty derogatory comments (especially from SolidWorks users) saying things like, "The programmers at SolidWorks should be made to use their own software."

This kind of thinking is similar to questioning the wisdom of asking a priest for advice on your marriage. After all, what the hell does a priest know about married life, right? And yet they are very effective in sorting out marital problems. I don't know about the West, but here in a place like India, they are wizards. For a doctor to be able to write a prescription for a patient, he does not need to be ill. Furthermore, the patient does not even know or care how other patients in the clinic feel. But the doctor does. All that matters to each patient is his health, that's all.

My point is that a user normally thinks only in terms of the software that he is trained to use. For the most part, he is unaware of features and methods implemented in other software. I see this every day at SYCODE. We specialize in developing data exchange plug-ins for almost all the major CAD systems and we get questions from customer of all shapes and sizes. The kind of queries that we receive make me sometimes wonder whether users wear blinders that prevent them from looking at all the other stuff around them.

Now coming to the view that the CAD media, analysts, authors, etc. do not use CAD software. I will let others speak for themselves. But before I have my say, let me list the CAD systems along with their versions that are currently installed on my computer in office.

Acrobat Pro Extended (9.0)
Alibre Design (11.0)
AutoCAD (2000, 2000i, 2002, 2004, 2005, 2006, 2007, 2008, 2009, 2010)
Bricscad and dozen other IntelliCAD variants
Cobalt, Graphite (V8)
CoCreate Modeling 2.0
DoubleCAD XT and Pro
Inventor (10, 11, 2008, 2009, 2010)
IRONCAD & INOVATE (11.0)
KeyCreator (7.5)
KOMPAS 3D (V10)
Moment Of Inspiration (1.0, 2.0)
Pro/ENGINEER Wildfire (1.0, 2.0, 3.0, 4.0, 5.0 Preproduction)
Rhinoceros (3.0, 4.0, 5.0 Beta)
SketchUp (6.0, 7.0)
Solid Edge (ST)
SolidWorks (2006, 2007, 2008, 2009)
SpaceClaim (2009)
TurboCAD (15.0)
VectorWorks (2009)

And these are just general CAD systems, not specialized CAD software like industry specific solutions for Rapid Prototyping, Reverse Engineering, etc. Now these CAD systems don't just sit there and occupy my hard disk space. I use these systems on a daily basis. I have spent the last decade solving people data exchange problems by figuring out how these CAD systems work internally. Apart from a few personal projects like designing my house and the stuff in it, I do not create a lot of design data. But I sure as hell modify data created by others. The data I am referring to here is live data from customers (or should I say users?), often sensitive information for which I need to sign Non Disclosure Agreements. The kind of stuff that eventually end up as products, buildings, etc.

But what is more important to understand is the fact that at SYCODE, we do not offer design services. Rather we offer plug-ins and custom solutions that automate the tasks of creating and modifying design data. So I need to wear the hat of a user as well as a programmer to be able to automate a user's workflow in his CAD system or between his CAD systems. So when someone refers to me as a non-user, you can imagine why I would find that a particularly difficult pill to swallow.

And lastly coming to the view that programmers should be made to use the software that they develop, I believe that apart from reflecting insolence, this kind of thinking shows stupidity in its purest form. I think this is best explained by means of an example.

Like I said before, at SYCODE, we specialize in data exchange plug-ins for CAD systems, one of which is SolidWorks. I find myself using the Import Diagnosis feature of SolidWorks a lot on models imported by our import plug-ins. It is not uncommon for the Import Diagnosis feature to not fill all holes and close all gaps because its success or failure depends upon the quality of the imported data. But sadly, it is also not uncommon for me to hear customers bitch about SolidWorks not being able to do a good job. Now consider this for a moment. A user will use a feature like Import Diagnosis probably a few times a month, if at all. Can you even imagine how many times the programmers who developed this tool used this feature to create, update, test, debug and continuously maintain their code? As programmers we use the software that we create after every tweak in our code and after every rebuild. We use our software with all kinds of design data that we can gather or conceive. We sometimes programatically create data that a user would normally never create, just so that we can stress-test our software. Heck, we use our software so much that we often need to write code that continuously runs data though our software on a dedicated testing server 24 hours a day, 7 days a week, 365 days a year. Think about it. If you are amazed at the speed at which demo jocks work, I suggest you take a look at programmers. Just because they work in the back room invisible to the world, it does not mean that they do not use the software they create. They use it far more than these so called users do. The reason I call this line of thinking stupid is because its more like a cab driver scoffing at a bunch of automobile engineers who designed the car that he is driving.

And while I am at it, I would like to draw attention to another thing I find quite repulsive. When a user creates a design and it fails or does not work as intended, he goes ahead and modifies it and gives it a revision number. In programming parlance the failure is called a Bug and the revision is called a Service Pack. Users should start calling their failures bugs and revisions service packs and then they will be able to appreciate the saying "to err is human".

I often hear users say that CAD vendors should sort out all the bugs before releasing their software and not make paying customers debug their software for them. I have even heard some users say that the CAD vendors should pay them for reporting bugs. I can turn this argument on its head and ask users to design products that never fail so that people who paid money for the products they designed do not have to pay the price for their "revisions" as well.

Sounds fair, doesn't it?

13 Comments:

  • Hello Deelip,
    You've an interesting CAD view again, and as often is the case, worth a read and a comment.

    I count 44 separate CAD applications/versions installed and in use on a "daily basis" on your PC!

    You certainly qualify as a 'user' though I feel, not as an expert nor even as a serious user, with maybe the exception of a couple of your favourites?

    Some CAD reviews I see owe as much to 'TV/Film' speak and colloquialisms (truly awesome, honestly amazing, multi-faceted, downright stupendifying...sorry, I made that one up) as they do to accurate technical reporting.

    How about handing the application under review to a bona-fide CAD user and then accurately reporting on how it performs on a real design task, deadlines and all?

    Regarding buggy CAD software and how much testing gets done; How come it still has bugs? The simple truth is that if the development resource went on maintenance instead of bells and whistles, we CAD users would quieten down some.

    Your comment "I do not create a lot of design data" and the statement that you do though, "modify a lot of data" speaks volumes. Surely your testing procedure needs to also create a lot of data? That is after all, exactly what a lot of CAD users are doing with the application:-) All CAD data is not created equal!

    Kind regards,
    Jonathan

    By Anonymous Anonymous, At 8:38 PM, June 13, 2009  

  • Jonathan: "I count 44 separate CAD applications/versions installed and in use on a "daily basis" on your PC!"

    Of course, I do not use all 44 every day. I'd go crazy. The product I use the most is Visual Studio (6.0, 7.0, 7.1, 8.0 and 9.0), the one that I develop the plug-ins in. As a result, at least one CAD system sits alongside Visual Studio to test the plug-in being developed, tested, debugged, maintained, etc.


    Jonathan: "How about handing the application under review to a bona-fide CAD user and then accurately reporting on how it performs on a real design task, deadlines and all?"

    I agree. There can be nothing better than a user reviewing a product under the conditions you mentioned. Too bad that many users don't do in depth reviews instead of criticizing those who do reviews. Now with free blogs you do not even need to create a publication. All you need is three things: (1) time, (2) the will to speak your mind; and (3) the ability to take criticism.


    Jonathan: "Regarding buggy CAD software and how much testing gets done; How come it still has bugs? The simple truth is that if the development resource went on maintenance instead of bells and whistles, we CAD users would quieten down some."

    Yes, this is a problem that I have highlighted on this blog before. I believe that this annual release cycle does put programmers under tremendous stress, which may result in cutting a few corners. Remember plug-in developers have to update and test their plug-ins every year as well. But my point here is that the programmers are as committed to making bug free software as users are committed to making fail safe designs.

    By Blogger Deelip Menezes, At 9:34 PM, June 13, 2009  

  • Deelip-

    RE:"I can turn this argument on its head and ask users to design products that never fail so that people who paid money for the products they designed do not have to pay the price for their "revisions" as well."

    I see a hole in this argument, for example: SolidWorks' number one priority is selling seats and creating a new version every 12 months. Therefore, due to a lack of time, they knowing release software that has bugs and that has not been thoroughly tested. Now I pay for the software and subscription maintenance very year, do you? So, during the past 10 years, I've spent over $40,000 for the software, maintenance, equipment, and overhead. In my opinion, this is significant. Stand in my shoes and Service Packs correct mistakes that SolidWorks knows about. Deelip, do you charge your customers for your mistakes? We don't. If we did, we wouldn't have any customers after a while. Do you work for free? We don't and can't. Yet SolidWorks expects us, the users that pay them for there software, to find and report bugs, for FREE. That's wrong.

    Thanks,
    Devon

    By Anonymous Anonymous, At 10:11 PM, June 13, 2009  

  • Also, SolidWorks expects us to pay for their mistakes too. They call them Service Packs, I call them mistakes. Every year, my Wife asks me, "Why do we pay for SolidWorks mistakes (Service Packs).

    Thanks again, good topic.
    Devon

    By Anonymous Anonymous, At 10:19 PM, June 13, 2009  

  • Anyway, documentation and interface. SolidWorks uses interface specialists. Sometimes this is effective, and other times not. I think for the interface, especially for complex interfaces like SolidWorks, sometimes maybe an overall plan of why it was done that way is necessary. There is too much expectation that the interface is simply obvious. It may be obvious from a certain point of view, but not from another. CAD philosophy and interface philosophy may sound like silly fields of study, but they are real

    By Blogger Matt, At 11:27 PM, June 13, 2009  

  • Devon,

    You are making quite a serious accusation here. If I have understood you correctly, you are saying that SolidWorks finds bugs in their software, does not fix them (due to lack of time) and goes ahead and releases the software. Maybe you know something that I don't, but I find this very hard to believe.

    I pay for some CAD software, not all. But I do pay Microsoft for the Visual Studio suite of products which I use to develop my CAD software.

    Service Packs mainly contain bug fixes that have been found internally or reported from the field. But there is something else about Service Packs that you may not be aware of. Visual Studio, like all other software, has bugs as well. Version 6.0 went up to SP6. This means that every memory leak that Microsoft fixes in a Service Pack is a memory leak that we developers have already introduced into our software that we have already shipped to our customers. The point I am trying to make it that there are certain things that are beyond our control. The tools that we use to make our software are themselves flawed. So obviously the software that comes out of them will be flawed as well.

    By Blogger Deelip Menezes, At 12:46 AM, June 14, 2009  

  • Deelip, you are fighting a losing battle against the users here. Then again maybe not.

    I can totally relate to your arguments and agree, with one fairly large exception. I know developers can use CAD software like wizards at lightspeed but whilst they know programming the one area they often get it totally wrong is in the interface. A lot, no most, CAD systems out there have crap interfaces from a user's point of view. You see the user will not be focussing on one tiny area of an application, they will use a larger set of features, and tend to see the bigger picture. And the people who are most vocal are the people who use the biggest range of features because they/we see the inherent flaws.

    Many years ago I argued with a developer on a forum for a certain piece of software (not SolidWorks actually) about a single tool. He argued that mathematically what the tool did was 100% correct. I argued that as a user/designer/engineer what the tool did was 100% wrong. ALL the other users chimed in and agreed with me. To this day the tool is still 100% wrong from the user's point of view! I don't use that software much anymore.

    Unlike many users I actually do pay for all the software I use from my own pocket (I say unlike many users because most CAD users work for companies who pay the bills - I work for my own company). I grumble about paying subs every year but I always pay it. I accept that bugs happen and I would rather have the software advance than stay static. service patches are no issue to me. But you have to realise that for a large installation running updates every month or two takes a lot of time and concern for the person responsible for doing the update in case there is a regression bug lurking in there that buggers up the workflow.

    Most issues in CAD software are not bugs in my experience but poorly designed interfaces or poorly implemented tools or poorly implemented interfaces to add on systems (like the D-Cubed constraints engine). If a user cannot access a function it is perceived as a bug when in actual fact it may well be "working as designed" but as designed by a programmer.

    I'm no coder, but I did run a company for a short while with a software programmer. It was a short lived enterprise. He insisted on doing everything. I came up with the ideas he coded them. What he did was fast and efficient but he just could not handle the concept of interface! What I mearned from that was that bog standard static interfaces are easy - they come as part of the MS tool kits. Complex interfaces - graphically rich, dynamic with drag handles etc are not easy. Which is why very few companies do them!

    But the simple fact is that if resources were diverted into interface coding and development of existing functions more users would be happy because they wouldn't run into hurdles all the time.

    Finally, your comment to Devon about companies releasing software they know is not ready... come on :-) We both know that happens. Anyone who participates in a beta or alpha stage programme knows features get pushed out semi finished. Maybe it is a difference in perception? Maybe from the coder's point of view all the "under the hood" stuff is finished but all the "skin deep" stuff needs a bit of polishing?

    By Anonymous Kevin Quigley, At 1:47 AM, June 14, 2009  

  • Kevin,

    Although this discussion is not about SolidWorks alone, I can see why it is becoming one. I am not taking up for SolidWorks management here. I am simply trying to point out that the programmers are not the bad guys here. I will leave it up to you decide whether the problem lies with the people who decide when a software should be shipped and it what condition. Remember one thing. Programmers did not decide that software should be shipped after every 365 days. I doubt whether their opinion was even factored in when making the decision.

    As regards user interface, different companies do it differently. Some software companies have a team of developers dedicated to user interface design and implementation. Others have one or two guys that do the ground work and the rest of the programmers plug in their code. I am not sure how SolidWorks does it, but from the public outcry, one gets the feeling that user interface was not something they could say was loved by all.

    By Blogger Deelip Menezes, At 9:44 AM, June 14, 2009  

  • Deelip, I'm responding to this thread and not your latest post but they are one in the same.

    Can we just be 100% clear here. Nowhere did I mention SolidWorks in my comments about pushing out unfinished software. Nowhere did I mention serious bugs getting shipped that cause crashes. This is not about SolidWorks. This is a general comment. I am an active participant in many software programmes at the beta and alpha stage. Small players and the biggest players and no I am not going to mention names.

    I am talking about bugs that are logged in the system as bugs, that are perhaps not critical but cause features to fail or behave inconsistently. These are bugs, they are logged as bugs and they are released as known bugs - just look at the release notes of any application under "known issues". In your utopian programmers world no software should be relased like this? Really? That is a recipe for bankruptcy.


    I have the greatest respect for programmers - it is all greek to me as they say. I could no more write a CAD application than run a 4 minute mile. Similarly those running CAD businesses have a difficult job. You cannot please every user all the time and by and large most CAD companies do a decent job. The most important thing a CAD company can do is remain a going concern and continue to deliver improvements. It is very easy for you or I to sit pontificating while the people at the top - well paid or not - need to make the decisions and please users, shareholders, employees and potential investors. This is why we have annual releases. There needs to be activity or the company is seen to be static. Can you imagine what Autodesk would do if SolidWorks moved to an 18 month or 2 year release cycle? and vice versa.

    So please Deelip, it is your blog and you can do as you wish but lets not turn this into an anti Solidworks thing or anti any particular vendor thing when those leaving comments did not say that. All that happens then is you get a mud slinging match and the argument is not progressed.

    By Anonymous Kevin Quigley, At 4:48 AM, June 15, 2009  

  • Kevin,

    To be fair, it wasn't me who turned this into a SolidWorks thing. But you are right. I assumed that you were talking about SolidWorks, like the other commenters. My apologies.

    By Blogger Deelip Menezes, At 6:48 AM, June 15, 2009  

  • The idea that the media/press/analyst community don't use the software is an accurate, in some cases - I've not a problem with that. As long as what they speak about is accurate, thought out and well constructed. The problem is that it often isn't.

    You're absolutely right with your Priest or doctor analogy. but both are trained in their profession and have a background of knowledge and resources at hand to make informed decisions and to give impartial advice. That isn't always the case in the press/media world.

    But from a personal point of view, I find it offensive and it's something I've discussed with Matt Lombard publicly and privately. Matt does an interesting job of throwing accusations out there, watching it explode, then throwing up his hands and saying "not my beef."

    And it's annoying.

    Because I spend most of my time as a journalist (I use the term lightly) he makes the assumption that me and the team I work with, don't use the software in anger. As I've told him time and time again, the truth couldn't be further from the truth.

    We all engage in professional product development and associated services that surround it. We license the software we use separately and privately. Why? Because there would be a huge conflict of interest and because we're professionals.

    If you want to talk about media pundits and bloggers discussing and diseminanting subject matter they're ill-equipped to discuss (at a VERY fundamental level), then that's a WHOLE other story man.

    Cheers

    Al Dean, DEVELOP3D

    By Blogger al dean, At 7:31 PM, June 15, 2009  

  • This is a great topic!

    What I would like to see from the press is more of a focus on unique examples, and real world applications.

    To frequently the press merely repeats marketing talking points.

    If a vendor claims "XXX% improvement" in a specific area, setup an independent test and try to validate the claim.

    That would provide a much greater service to your consumers.

    As far as programmers releasing code before it's ready, I don't think that is a general trend in the industry. Programmers want to produce quality work as much as anyone.

    By Anonymous Anonymous, At 2:24 AM, June 16, 2009  

  • Anonymous: "If a vendor claims "XXX% improvement" in a specific area, setup an independent test and try to validate the claim."

    I agree completely. That's is why I try not to mention stuff in press releases unless I have something else to say about its content.

    By Blogger Deelip Menezes, At 10:19 AM, June 16, 2009  

Post a Comment

Subscribe to Post Comments [Atom]



<< Home