A Conversation With Shyamal Roy – Part 1

Shyamal Roy is the Founder of GEOMATE, the maker of GrafiCalc – a pretty unique piece of software for engineers. I first met Shyamal at COFES 2008, where he was my host. Every freshman at COFES is assigned a host who helps him or her get connected to the other attendees. Shyamal happens to have some pretty interesting views on the CAD software industry. Here is part of an email conversation that I recently had with him. I have rearranged it a little to fit the question and answer format.

Deelip: Whenever you and I have sat down at COFES and discussed the CAD software industry you always mention what you call the “build-test-fix” paradigm and why you think that sucks. Can you elaborate a little more on that?

Shyamal: Deelip, first, it is not only me who calls it the “build-test-fix” paradigm – this is a well-known expression. If you Google build-test-fix, you will get over 6 million hits. Second, my premise is not that “build-test-fix” sucks. I believe the “build-test-fix” product development paradigm fundamentally violates the mechanical design process and has spread like a bad cancer in the user community. Unfortunately software vendors are locked into technology that does not permit a cure. And users and analysts are in denial.

It is well known and accepted that mechanical design process starts with a statement of product functional requirements that may come from marketing, an invention, or recycling an older product idea. Closely influenced by the product functional requirement are the product’s form, materials, and manufacturing process. These four variables – function (how the product works), form (how the product looks like), materials, and manufacturing processes – are of major concern to the product developer and approximately follow the 80/20 rule – decisions made in the first 20 percent stage of the design process influence 80 percent of the final product cost and performance. (Note: I strongly recommend Prof. David Ullman’s textbook “The Mechanical Design Process” that covers the above-mentioned subject authoritatively).

Today, all CAD systems oblige users to start the design based on what the product looks like and not how it works. Then analysis is done to find out if the design will perform as expected – which it does NOT in most situations – and then back to the drawing board (modeler). This cycle continues until an acceptable product is designed or the user runs out of time and money and commits to whatever is done and hopes that outsourcing the manufacturing will somehow reduce the product cost. This “build-test-fix” cancer today, IMHO, is perhaps the 2nd biggest factor adversely affecting the economy of product developing countries after the crooked financial institutions. Just ask any laid-off mechanical engineer in the manufacturing industry in the USA.

Deelip: So what is the solution that you propose?

Shyamal: Before I get into what solution I propose, I would like to enlighten you with solutions that have been proposed. Sometime in the mid-eighties several people started recognizing this fundamental error in the design process. They were inspired by the design paradigm in the chip industry where one could not dare start a design without prior simulation using CAE tools. So a number of companies were started to create a new genre of products in the MCAE (Mechanical CAE) arena. To name a few, Phil Villers, founder ComputerVision, started Cognition, legendary Jon Hirschstick started Premise to offer the DesignView product, and Bruce Da Costa developed Mechanical Engineering Workbench. In less than 5 years these companies failed to exist after spending several millions of dollars – Jon of course quickly recognized the “denial” factor and moved on to start super successful SolidWorks but the others dwindled into oblivion.

At the same time I had also started working on a product internally called ICAN (Integrated Computer Aided Napkins) that would allow users to sketch constrained geometry and perform geometry-associative calculations in the same worksheet. I was closely following the above-mentioned companies to find out what to do and NOT do.

Interestingly there was one thing common among the early companies; all of them adopted the Variational Geometry technology developed by MIT CAD labs for constraining the sketch. I felt the Variational Geometry technology was an elegant solution for capturing form but was not efficient for capturing functional intents. It seems I was right in making that call, because today virtually all CAD sketchers use the Variational Geometry technology for initial sketch creation, while all products that used the Variational Geometry technology for function modeling were not successful. I can get into the technical reasons behind my thinking that would perhaps be beyond the scope of this discussion.

So the solution we developed had two pioneering enabling technologies from the ground up. For sketching geometry we developed a matrix-based constraint manager with pre-solved constraints that work as objects. And for calculations we developed a game changing geometry-synchronous graphical calculation technology that enables users to solve a wide range of mechanical design challenges without performing any mathematical calculations and solving tedious equations. After developing the enabling technology we established a large number of “lighthouse” customers to guide us for packaging the technology – I believe users are the vest experts and I wanted to develop user-driven products.

So the solution we propose is GrafiCalc, a Pre-CAD design simulation software, that is smaller than a diamond and faster than a bullet, that helps users to conceptualize, analyze, and validate all critical engineering and manufacturability parameters before committing to the final design.

Part 2 >>