Mechanomy

Software for Pre-CAD systems design

Mechanomy's Fifth Birthday

designengineeringmanufacturingwritingsubstack

See this post on Substack

Today, January 16th, is Mechanomy’s fifth birthday.

It’s hard to say more than that, not because there haven’t been ups and downs, but because so much remains pending, awaiting fuller realization. The best things have been getting prototype tools to work, often in some new language or library, which further proves my vision for Mechanomy and says, ‘well these parts are very close to ready’, that the capability is works and awaiting application and integration. On the negative side is the ‘weakness’ of the market, in that I’ve struggled mightily to find any overlap between what the market wants (is presently buying and is being advertised), what the market needs, and what I can offer:

The overlap of these three is where I should focus:

The problem is that market needs are only coarsely known; while market wants can be determined by what is currently being sold and bought, tomorrow’s needs has a very soft edge. This makes my product development choices risky.

It is straightforward to build a competitor to some existing capability, as solution and customer are both visible and the only question is whether your new solution is better than the existing. At my current size, engineer-focused website development is an obvious direction, where my wide familiarity with the industry would allow me to understand clients and their end customers better than less-focused webdevs. Parts of this can be seen in my design tools, which demonstrate capabilities that are straightforward yet widely absent on engineering services and manufacturer websites.

Developing the backend framework and competency over multiple clients spreads out the cost, while charging for the initial build and ongoing operation points the graph somewhat upward. Attention to detail in the construction of modern, customer-focused capabilities would, in some small way, make the end-customer more confident in their purchase decision, thereby advancing the interests of my clients, their customers, and our society broadly.

But as this would be targeted at the market’s existing wants rather than its needs, it can’t do much to improve the situation today. And I see a ton of things that want effort and improvement. Despite this, no one really knows the market’s needs; all anyone can do is build bridges from today to tomorrow.

These bridges vary widely; the most expensive are designed by teams of marketers and erected by sales staff and value-added-resellers. They’re expensive because the bridge generally works, it does get you from the previous version to the next, and you had a good idea of where you were going throughout. Other bridges are spendthrift, consisting of little more than some planks laid across a creek; dangerous when crossing a canyon but acceptable over shallow water. Their goal is merely informational: the new version has these capabilities, acquire it here. This is the norm for software and libraries distributed by GitHub and others, no frills, no expense.

The goal of this substack is to build bridges to the capabilities that I and other engineers want to use to build tomorrow. As much as I want to skip to building tools and capabilities, it’s become very apparent that I cannot do so at Mechanomy’s present scale.

Instead of directly building individual capabilities and then searching for users looking to solve only that single problem, I plan to take an iterative, outside-in approach, first describing how I understand various problems, what I make of the various solutions presently existing, then requesting information from readers to critique the various proposals. The hopeful result will be a more concrete understanding of a need and its possible solutions, some of which Mechanomy may be able to provide.

I like this approach because writing a post is cheaper than writing and releasing a library: in both cases I’d like to convince you that my approach is a good, or even better way to solve a problem, but the latter has the potential of wasting time on unnecessary functionalities and will still need and introduction and some promotion. This approach is similar in spirit to building-in-public, the idea that by openly journaling the development of some thing, that the thing will be better because of the public’s involvement (in some form) in the development.

One parting motivation is that I do not know where design engineers hang out, where or even whether they grouse about the frustrations implicit in every engineering tool. These frustrations arise from negative externalities, the unintended consequences of decisions made elsewhere, yet if denied expression, will never be fixed. In this and many other aspects, community is a good thing and we will benefit from more of it.

Software engineers are conspicuous in their public advocations for their spiffy, new way of toggling bits, but mechanical engineers and product designers are not. From the outside, few appear proud of their work. In later posts I’ll go into some reasons for this and what I think we can do about them, but one basic point is that software is easier to copy than hardware, the result of which is that the traditional close-minded approach to what is assumed to be intellectual property is highly damaging to our work, companies, profession, and society and its past time that we advocated for ourselves.

I hope that this journey will be interesting and encouraging to my fellow design engineers, please subscribe, follow, comment, reply, or otherwise engage.

— Ben Conrad