[Strangework]

So wild! Such a surprise to find this on the front page of Hacker News. If it weren't for the author's username, I might have missed this gem.

I had worked at Edenworks as a software engineer for a few years, alongside Johnny. I don't pretend to know enough to speak on manufacturing itself, but Johnny's remarks on software development are spot-on.

When I had come onboard, I had naively suspected a typical software startup experience; rampant technophilia with an obsession for integrating the freshest software technologies. If 'Software is King' is true everywhere else, why shouldn't it be true here?

Edenworks is not a software startup, however, and it's important to realize that. Manufacturing is an entirely different beast, which makes steady, deliberate movements (i.e. it doesn't move fast, and it shouldn't break things). When the main product being developed is a tangible system, redos are way more costly. Adding flashy software features does not expedite this; lashing the latest and greatest Javascript library onto the fronted does not add value... not reliable value anyways.

When it comes to developing a manufacturing process, software should be flexible and let the process demands come first. The typical workload is more concerned with running test trials than hacking up something new.

For me, this realization was more emotional than organizational - sometimes you have to curb your hype. To add real value to the product, I had to watch my ego. In a manufacturing company, the Process is King.

[m_eiman]

When the main product being developed is a tangible system, redos are way more costly.

Even when primarily doing software, this can come into play.

I know of a customer who had about 5000 card readers in an access control system, where bugs in the card reader firmware required a firmware update. Doing this required walking to a reader, unmounting it from the wall, updating the firmware, re-mounting the reader. Rinse and repeat 5000 times.

A rough estimate is that upgrading all the readers on the site took about a man-year of technicians walking around updating things. Let's just say that when more bugs were discovered, the customer who paid for it all was less than pleased…

Lesson learned: always make secure remote firmware updates possible on your devices.

[SixSigma]

> Lesson learned: always make secure remote firmware updates possible on your devices.

Lesson apparently not learned: get it right first time.

Software isn't special

http://www.gettingitrightfirsttime.com/report/

[m_eiman]

Software IS special. Compared to hardware, software is (usually) so easy to update that it's (usually) cost effective to not do it right the first time. NASA etc is different, and they work differently.

Everyone knows this and act accordingly - which is why we have to live with ever changing requirements for projects.

[Dayshine]

Er, but the case study you linked is very different.

There they're talking about getting specific tailored treatment right the first time.

Here we're talking about getting a generic reusable component right the first time.

Which is exactly what that link advocates against...

[moron4hire]

This is only because the electrical and mechanical engineering realms have been resistant to change. There are rapid prototyping techniques that can be used to improve the hardware side, and so much of the latest systems are built largely in software anyway. There are still hardware shops debating whether or not source control is a good idea, "we tried CVS once, it didn't work."

The quality of a system is a direct function of the speed of the testing cycle. To argue "slow, methodical, reasoning" is to argue against quality.