Hacker News new | ask | show | jobs
by InternetOfStuff 2472 days ago
> However, I still think waterfall is the only approach when trying to design a hardware product. Electronics require pretty specific requirements up front before you design and order boards, obviously mechanical tooling can be even more expensive.

I disagree, having taken part in agile embedded development.

Sure, it looked a bit different from pure-software, but the same underlying principle of short iterations applied. Our definition of "short" was a bit different, but still...

And yes, you may have some "very specific" requirements, but you may also have some "pretty loose" ones -- just like software.

> But... I think there are lots of ways to do quick experiments and tighten up the feedback look even with robotics or electronics. Breadboards and development kits can be used as initial electronics prototypes. 3d prints help test a mechanical concept

See, there you go.

The core idea behind Agile isn't to have sacrosanct two week sprints (or even to have sprints in the first place), it is to close as many feedback loops as you can as quickly as you can. Whatever that means in practice.

This has been good engineering practice for longer than software exists.

I read that the Mercury space project created their software in half-day "sprints". Back in the '60s, on punch-card machines (I guess).

2 comments

Maybe I am wrong in my understanding, but for agile to work, observations from testing or using is fed back quite quickly so that fixes can be included in the next sprint. For the hardware where the validation can be quite lengthy, this is feedback loop is much, much longer. Especially true when the project gets closer to start of mass production.
> Maybe I am wrong in my understanding

No, not at all. Just maybe a little... narrow?

> observations from testing or using is fed back quite quickly so that fixes can be included in the next sprint.

Quite quickly, yes.

The next sprint...maybe? Not necessarily.

Sure, you'll stick it in the backlog. But whether you'll start working on this improvement immediately is a separate matter. If that's the best course of action, sure, do it. But maybe you have more pressing matters, and the present implementation will do for now. Or... it's not possible to attack it in the next sprint, because a new board needs to be spun, and that takes preparation. Then it'll be slated for the appropriate time, by necessity. That doesn't mean you forego an agile approach -- it just looks different, because the landscape is different.

> Especially true when the project gets closer to start of mass production.

Sure. Which is why being able to make, and find, and correct your mistakes early, when it's not so dramatic yet, is the goal of that whole Agile song and dance.

As you're intimately familiar of course, surprises in engineering are usually the bad kind, and the later they come, the worse they catch you. So, have as much feedback as you can, as early as you can (and with as much fidelity as you can).

What you are describing is common sense engineering, of which Agile also incorporates those aspects of as well.
The philosophy of making the feedback loop as tight as possible is independent of any one particular value of "possible."
I think your last sentence is an example of semantic drift.

I don't think a single compile cycle per half day meets most people's definition of a sprint...

>I don't think a single compile cycle per half day

Hm... I read this quite differently than you do. Not compile cycles, but actual test-driven product iterations.

Do you have more solid sources than I do?

https://intenseminimalism.com/2012/a-brief-history-of-agile-...

https://brettwgreen.com/2014/01/25/rockets-before-rovers/

Let's check those sources.

1) "A brief history of agile methods" asserts:

1958 — Project Mercury (NASA) software development, ran with half-day iterations.

The only thing that looks like it could be intended as evidence for that assertion is the Larman and Basili article.

2) "Rockets before Rovers" asserts:

Project Mercury did half-day iterations with test first development!

The only thing that looks like it could be intended as evidence for that assertion is the Larman and Basili article.

3) So there only seems to be one source — Larman and Basili "Iterative and Incremental Development: A Brief History" — which asserts:

"Project Mercury ran with very short (half-day) iterations that were time boxed." page 2

[pdf] http://www.craiglarman.com/wiki/downloads/misc/history-of-it...

Where's the evidence for that assertion?

afaict the Larman and Basili article does not provide a source as evidence for that assertion?

So we're left with nothing.