Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Iterative development: the secret to great product launches

mindk.com

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Iterative development: the secret to great product launches

#51

Post by andy_ppp »

lmm wrote: post #44
shadowtree wrote: post #42

Earlier quoted context omitted.

"A complex system designed from scratch never works". And yet we flew to the moon. And have airplanes, and and and. A lot of agile is just an excuse for software "engineering" being in the throw shit at the wall and see what sticks stage of evolution. Construction went through the same, software has freemasons now. But no engineering whatsoever. Example: People still write their own date conversions (and fuck it up).

> And yet we flew to the moon. And have airplanes, and and and. We do, but not by designing from scratch. We achieved those things by incrementally extending existing designs and verifying that the newer, more complex designs had the desired properties . > A lot of agile is just an excuse for software "engineering" being in the throw shit at the wall and see what sticks stage of evolution. Construction went through t…

The people making the planes made meticulous changes to the design before anything was built so I really don't think your point is supported by aeroplane manufacturers. The builders weren't just told make it faster and more fuel efficient and to get on with building it.

Re: Iterative development: the secret to great product launches

#52

Post by kitotik »

nadam wrote: post #30

Agile, MVP, Iterative development: these are common knowledge by now. But I think there are problem spaces where this does not really work becasue even an MVP must be huge, otherwise users will simply ignore the product. You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite, etc... I think markets in problem spaces where you can start with a very small MVP…

Amidst the Lean startup and agile craze, the concept of a set of ‘Minimal Marketable Features’ seemed to have been lost.

‘Minimum Viable Product’ is not the same as a product that is ready to capture real market share, just a validation checkpoint(ideally one of many).

Re: Iterative development: the secret to great product launches

#53

Post by Jtsummers »

kabouseng wrote: post #6

It should be stated that iterative development does come with a cost in that it takes longer to execute than the ideal case sequential development. You trade risk reduction for more work.

> it takes longer to execute than the ideal case sequential development. [emphasis added]

That's not true. In the "ideal", they both take the same time. Why? Because in the ideal they both include exactly the same amount of work (assuming your testing story isn't 5 months of manual test execution). If you have a sane system testing setup, they're exactly the same.

But the fact is, you never have the ideal. And that's why you use iterative methods. You will almost always design the wrong thing (at least in part). You will almost always have a section of code that's harder to implement than originally anticipated (or whose initial implementation impedes other work, requiring a partial rewrite).

Iterative methods discover these issues earlier. In a sequential (Waterfall) development model, you only discover these problems in the late stages, far after you've initially designed and developed. This requires you to go back and redo a lot of stuff, or you put in patches and compromise on quality, or you accept that it's a failure but ship it anyways.

========

Now, if your test story isn't sane and it's all manual testing, then sure, iterative methods will by necessity be slower because you take months to test each iteration. So fix the test story so that it's as automatic and fast as possible (without compromising the test quality). At that point, sequential is only best if you have a perfect team that never fucks up, and a perfect customer who never asks for the wrong thing. Since we all know that those things never happen (in large scale projects [0]), don't make that assumption (you do know what assuming does, right?) and stick with iterative methods.

========

[0] A thing that's often forgotten in these discussions is that Royce's paper was about large scale engineering tasks. Not small stuff. I will concede that a Waterfall-esque approach can work fine for a short-run (less than one quarter), small-scale project (especially if it's in a well-understood domain). But in anything past that 3-6 month mark or on any poorly understood domain, sequential is the worst thing you could do to your team and your customer.

Re: Iterative development: the secret to great product launches

#55

Post by [deleted] »

shadowtree wrote: post #42
lmm wrote: post #18

Earlier quoted context omitted.

> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. On small teams this might be marginally possible but still difficult - on largers ones (> 5 people) leads to madness and failed projects. I'd say that the biggest failures I've seen have been due to having a specification, and the bigger the project the more important it is no…

"A complex system designed from scratch never works". And yet we flew to the moon. And have airplanes, and and and. A lot of agile is just an excuse for software "engineering" being in the throw shit at the wall and see what sticks stage of evolution. Construction went through the same, software has freemasons now. But no engineering whatsoever. Example: People still write their own date conversions (and fuck it up).

[deleted]

Re: Iterative development: the secret to great product launches

#56

Post by Jtsummers »

shadowtree wrote: post #42
lmm wrote: post #18

Earlier quoted context omitted.

> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. On small teams this might be marginally possible but still difficult - on largers ones (> 5 people) leads to madness and failed projects. I'd say that the biggest failures I've seen have been due to having a specification, and the bigger the project the more important it is no…

"A complex system designed from scratch never works". And yet we flew to the moon. And have airplanes, and and and. A lot of agile is just an excuse for software "engineering" being in the throw shit at the wall and see what sticks stage of evolution. Construction went through the same, software has freemasons now. But no engineering whatsoever. Example: People still write their own date conversions (and fuck it up).

Those weren't designed "from scratch", start-to-finish, with no testing or prototyping along the way. The Wright Brothers developed a wind tunnel and many models on their way to first flight. Same concept for getting to the moon.

Those large scale projects were not done in a Waterfall fashion, they were done iteratively with models/simulations/prototypes produced along the way.

Re: Iterative development: the secret to great product launches

#57

Post by cheez »

lbacaj wrote: post #27

I have built many things in my short career, have worked at big and small companies. In my view iterative development is far harder, maybe even impossible, to do at companies that don’t have the culture for it. Startups have it and most grow up with it but you’ll struggle to succeed with this approach at any big company. They may introduce Agile and bring in Agile coaches but they are just putting lipstick on the pig…

With large companies, I find what works well is "this is going to take 5 years, what should we do in a month?" From 0 to working in a month usually gets the check writers to open up.

Re: Iterative development: the secret to great product launches

#58

Post by zild3d »

nadam wrote: post #30

Agile, MVP, Iterative development: these are common knowledge by now. But I think there are problem spaces where this does not really work becasue even an MVP must be huge, otherwise users will simply ignore the product. You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite, etc... I think markets in problem spaces where you can start with a very small MVP…

> You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite

"MVP" tends to wind up meaning vastly different things to different people

who says you can't leverage what's out there to build any of these complex things? An MVP of a new browser might start out as a chrome extension, or a fork from chromium. An MVP of a new search engine can leverage google, and bolt on some custom thing to the end of it

Tesla for example built the Roadster starting with leveraging a https://en.wikipedia.org/wiki/Lotus_Elise frame

Re: Iterative development: the secret to great product launches

#59

Post by Jtsummers »

kitotik wrote: post #52
nadam wrote: post #30

Agile, MVP, Iterative development: these are common knowledge by now. But I think there are problem spaces where this does not really work becasue even an MVP must be huge, otherwise users will simply ignore the product. You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite, etc... I think markets in problem spaces where you can start with a very small MVP…

Amidst the Lean startup and agile craze, the concept of a set of ‘Minimal Marketable Features’ seemed to have been lost. ‘Minimum Viable Product’ is not the same as a product that is ready to capture real market share, just a validation checkpoint(ideally one of many).

I want to +1 this but also add to it.

I worked on a safety critical system (among many others, but this one in particular) that was developed in an iterative fashion. The "MVP" was not sufficient for fielding the aircraft, it was sufficient for testing the aircraft. Each successive iteration was meant to be closer to what was needed for later testing stages, and finally a release that was good enough (not feature-complete, but complete enough) to allow for carrying passengers.

Most of the later additions were "nice-to-haves". They provided better reporting and recording of issues, better BITs (built-in-tests) which reduced maintenance effort, etc. Nothing essential for safety, but useful for improving overall quality-of-life issues for the operators and maintainers.

Each stage also ensured that we were building what was actually needed (reporting the right kind of things, reporting it in the correct way, etc.) before we spent millions of dollars and years of effort on the wrong thing.

Re: Iterative development: the secret to great product launches

#60

Post by oldboyFX »

andy_ppp wrote: post #16

I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. On small teams this might be marginally possible but still difficult - on largers ones (> 5 people) leads to madness and failed projects. My other pet annoyance is management still seems to think that adding more resource to a project makes it faster. Especially "cheaper" resour…

Speaking from first hand experience, it is possible to build efficiently without detailed specifications. The key is to put boundaries between different parts of the application and allow each developer to take full responsibility for delivering their part.

I've had some horrific experiences where multiple developers worked on the same features (without specs) while stepping on each others toes.

Post reply on HN