[nbadg]

After working on hardware teams in various capacities for 6 or 7 years, I'm not surprised. Startups need momentum - especially massively successful startups. And hardware, at this point in time, isn't something that you can easily build momentum with.

Don't get me wrong, I don't think this is because of any inherent difference between hardware and software. Sure, the requirement to physically build something adds a bit of a delay, but computer simulation is so good these days that the actual building bit is pretty infrequent. Plus, turnaround time is usually pretty short - two weeks lead was pretty standard for the shops I've worked with and at.

No, the problem IMO is that frankly, our software is shit. The end users of, for example, Solidworks, aren't the people paying for the software, so there's no direct market feedback. Mechanical design software was some of the earliest software ever written, and it's been some of the slowest to change. The hiccups are negotiable if you're working serially and alone, but the second you want to do parallel development on something, or to collaborate with anyone else, you're stuck throwing workaround after workaround on an already slow process. And then there's the catastrophic state of CAM software, BOM integration, inventory management, keeping the books on all that... everything is its own walled system, nothing talks to anything else, and everything sucks. I've spent literally days before duplicating information between Arena and Solidworks drawings -- and they even actually have an integration.

I'm wholly convinced hardware unicorns are so rare because the toolchain we use to build hardware is so bad. It stays bad for historical and short-sighted economic reasons. That is to say, the whole situation is ripe for change. And it's not hard to do, either: I coded up 85% of an MVP for a solid model merge tool that would make solidworks files more or less git compatible in just a month or two. If you want to play with that, it's a hacked-up VBA macro called smgimport/smgexport available here: https://github.com/Badg/SolidworksUtils. I have a lot of thoughts on how to do this right. If you're working in this space and want advice, I'm happy to help.

[nl]

I think your point regarding how bad hardware-design software is correct.

But I think that understates the many other problems with hardware.

Just off the top of my head, the following are problems that are incredibly hard to solve for any new hardware company:

Distribution (how do you get your device into the physical and online stores where people buy)

Logistics (how do you bring the parts together, make sure you always have the correct parts, ship them to distributors etc)

Fast followers (If you do have a good device, why can't an existing manufacturer copy what you made and use their better distribution to outsell you and their bigger scale to get better prices on parts?)

Regulation (Many hardware devices need certification of various kinds before you can even try to sell them. I'm not opposed to this, but it is harder than in the software world)

etc, etc

[nbadg]

So I am definitely making a development-centered critique. Partly that's because most of my experience is in development, and I have very little experience in high volume product or DTC. However, I also think that the software problem is a whole lot wider than design, and that the state of software for hardware companies as a whole (including logistics!) is abysmal.

Distribution of physical product to stores is something unique to consumer goods, and for physical hardware I think that landscape is currently experiencing a great deal of change. Even ignoring marketplaces like Amazon, we're starting to see the emergence of distribution / fulfillment as a service, and the burden of entry into the online retail market is much lower. Many very successful hardware startups have gone in this direction first, only arriving at brick-and-mortar retail stores once the company is large enough and established enough to spare the resources to keep that up.

Logistics and supply chain management are basically managed by software at this point, but because there's no effective integration between software (even packages that have the integration botch it) means that it's actually in some ways made into a harder problem because the data is stored in 10 "convenient" places rather than a single unconvenient place.

The fast followers / competitors problem is, I think, actually a bigger problem for the software industry than the hardware industry, with the exception of offshoring. If you offshore, particularly to China, and don't have a very good relationship with the factor(ies) you're working with, this is a very real risk, if the entirety of the widget is being produced by that one factory. With more complex widgets, this risk is substantially mitigated. In general I'd say this is more a function of the quality and uniqueness of the product coupled with your execution on it than something inherent to hardware. This is not, however, a problem that good hardware software will solve. The ability to rapidly develop things will actually make this worse. I don't have a problem with that! Execution is everything, even in entrenched industries, and Davids have always managed to topple Goliaths.

Regulation is also, in my mind, being held up by software. There's certainly a component that's out of your control - once you fire off the paperwork, you just sit and wait - but there's a lot you can do to smooth the approval process on your own end, and a lot of that has to do with proper design documentation, which is once again suffering from terrible software.

I'm not trying to say that having better software for hardware will fix everything. It certainly won't. But, I do think it is the single greatest limiting factor by far in hardware production. I would estimate it consumed 80% of my productivity or more. It's an astounding timesuck.

[bsilvereagle]

For something this complex, you may have an easier time with C#. All of your enumerations get Intellisensed, for example.

I also recommend creating a standalone C# application, rather than trying to fit in the confines of a typical Solidworks Macro. Sure, you don't get a little button in the toolbar saying 'Export/Import', but instead you have the full flexibility of a console (or graphical diff potentially) application.

In the short term (I noticed your last commit was 7 months ago), you may/may not know about the Solidworks 'Compare' utility. In 2015, Tools->Compare. In the Solidworks Tutorials there is a small and trivial example of using it.

Interesting idea overall of trying to encapsulate a SLDPRT as a yaml. I imagine that assemblies are going to be a bear in this fashion.

Have you looked into trying to reverse the SLDPRT file format? It must be possible if other companies are offering the option to import a SLDPRT (I believe the last time I used Creo there was a MVP importer).

[nbadg]

I'd definitely have an easier time overall with C#, no questions asked. I actually tried it briefly, but after a week of not being able to get a development environment communicating with Solidworks, I decided it was unjustified for making an MVP.

It's actually been a whole lot longer than 7 months since I worked on it. The whole thing was basically one monolithic commit I did after writing the snapshotting utility while doing release documentation for a product I was managing. Since then (and even while I was working on it) I've thought of a lot of much better approaches to this than I was taking with the macro. The macro was just a very early proof of concept. I'm also not totally sold on the yaml choice, I can see a lot of reasons to go with an open binary format -- but I think part of the success of JSON has been predicated on its choice of universally-parseable text. The ultimate goal would be to create a new CAD program marketed towards the sub-$100 software market. I'd couple that with a version control system specifically tailored (even if just in UI) to a hardware workflow, and then get recurring revenue from a github-like service. Really neat project and I'm confident I could execute on it successfully.

Except I've actually put this project on hold while I work on something more important to me - creating, implementing, and financially sustaining an open, encrypted, distributable social networking protocol (https://www.ethyr.net/blog/muse-101.html). Fixing solid modeling is an awesome and potentially very lucrative endeavor, but it's much less timing sensitive (and much less personally meaningful) than my current project is.