Hacker News Reader

Comment by drewcoo | Hacker News Reader

How does the hardware talk?

If it's not via software, I'm willing to bet the hardware is not remote. Or if not exactly software, it's contractual signaling, which we can model and understand and MITM in software.

If it is by software, we can model these problems just like software. Known problems with known solutions. With the understanding that individual systems may incur side effects (like hardware bugs or . . . UI!).

Most of this is not about hardware and a lot of it is unproved conjecture. There is also a smattering of hardware-specific knowledge (this wears out that way!) that is not about building large systems, but about problems in the small.

View on HN

It's not the hardware which is "remote" but the team, i.e. a set of people working from home in different places rather than lab workbenches.

I think the parent has a point as the author makes a big deal of how this hardware supports their remote work.

It’s clear to me oxide are having fun, and while you could do some of this in software, you clearly couldn’t do that without some hardware. Could they have purchased the hardware instead? Probably. Would it have been as cost-effective or fun? Probably not cost effective, without shifting their staffing. Does anyone have fun purchasing OTS development hardware? You’re just gambling on what systems and complexity in their own stuff they’ve really tested.

Changing staffing is hard, expensive and painful. Repurposing apparently excess hardware development folks to fill the gap here is interesting, not the way hardware is “usually done” and seems to be working.

OTS development hardware is fine for very initial prototyping/derisking phase, but as your product evolves you need your development hardware to match the hardware in the field more closely.

Yes but all hardware companies do that, and that is not what the author seems to be discussing. The article seems to me to focus on the unique nature of making hardware tools to support remote work.

>Could they have purchased the hardware instead? Probably

Uh, from the article:

>We use many off-the-shelf development boards and even provide support for a number of these boards in Hubris. These are great for many use-cases, but less great when we are trying to model specific circuits or subsystems of our product designs. Second, we have numerous examples of custom boards that were built simply because we could find no useful OTS (off-the-shelf) alternative.

Yes but here the author mixes tool-making and product de-risking. I was talking about tool-making which seemed to be the unique part of the article. Everyone designing hardware products designs some hardware.

You can almost always make tools and test equipment with general-purpose hardware. There are companies that design hardware intended to be used like that. People tend to (understandably) try to drag problems into domains where they are comfortable solving them. In this case they tended to draw solutions from hardware but a software team probably would have solved them a different way.

Reply on news.ycombinator.com