Live data from Hacker News

Iterative development: the secret to great product launches

mindk.com

41–50 of 77 posts

Re: Iterative development: the secret to great product launches

#41

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.

This is the conventional wisdom, but in my n=1 experience, I have never seen the “ideal case sequential development” actually work in the wild. The ideal case presumes that everything is known when the sequential development is planned, which is what permits it to be optimized. But in my n=1 experience, everything is not known, the development team is constantly discovering new information, requirements change, and t…

There is the pressure though to deliver this small feature ASAP, rather than putting in the work to make it flexible enough for the stuff that's highly likely to come down the road.

For a lot of things it doesn't matter, but for some it can be very difficult to change later on, especially if you need to maintain backwards compatibility.

Re: Iterative development: the secret to great product launches

#42
post #18

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…

> 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).

Re: Iterative development: the secret to great product launches

#43
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…

From what I have seen, the first version is more iterative. When the inevitable re-write happens, architecture astronauting happens. Devs get this mindset that they can build a Neo[0] system that can handle any future feature request and so the product stalls. And stalls. And ... well you get the picture.

[0] "The One..."

Re: Iterative development: the secret to great product launches

#44
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).

> 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 the same, software has freemasons now. But no engineering whatsoever.

The constraints that apply to software are very different from those that apply to construction. What if "throw shit at the wall and see what sticks" really is a better way of making software than "engineering"?

> Example: People still write their own date conversions (and fuck it up).

Indeed they do. Do you find this is more common in projects that specify and design up front or in projects that don't?

Re: Iterative development: the secret to great product launches

#45
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, etc

I don't think that's true at all. You absolutely can and should build an MVP of all these things. You certainly could release an MVP search engine (or even a browser-based game). You probably can't hope to gain traction at large with an MVP browser or operating system, but you can start using these things internally and dogfooding them.

IMO, iterative development isn't necessarily about releasing something fast to the public, it's about rapidly building a working version that you can interact with, test properly as a whole working system and show people, so you can quickly figure out what are the most obvious issues to address and improvements to make. You can test this software internally, show it to your friends, have a small private beta or even hire testers depending on your project and budget.

This is in contrast to a more traditional/naive development model where the team isn't even trying to have a working/testable version, and instead focuses on spending weeks/months building components separately, which they hope will come together into some grand vision at the end. This approach is terrible because things likely won't come together seamlessly. The different components can fit together poorly, effort is wasted on features that weren't actually good ideas in hindsight, etc. Software projects developed this way are often late, overly complex and poorly designed.

Re: Iterative development: the secret to great product launches

#47
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…

[deleted]

Re: Iterative development: the secret to great product launches

#48
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…

From what I have seen, the first version is more iterative. When the inevitable re-write happens, architecture astronauting happens. Devs get this mindset that they can build a Neo[0] system that can handle any future feature request and so the product stalls. And stalls. And ... well you get the picture. [0] "The One..."

I think experiencing that kind of behavior is what led Joel Spolsky to write about how you should never rewrite something from scratch https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Re: Iterative development: the secret to great product launches

#49

The longer I work in this industry, the more I am coming to believe that waterfall is nothing more than a strawman set up to make development process X look like the Holy Grail. Has anyone seen it in real life - in the pure form? I once worked at a place that "did waterfall", but a diagram of the process would have shown arrows in all directions (would we call these things salmon runs or something?) and if you needed…

> a strawman

"Figure 7. Step 3: Attempt to do the job twice - the first result provides an early simulation of the final product."

1970 "Managing the Development of Large Software Systems"

"Figure 3 portrays the iterative relationship between successive development phases for this scheme. The ordering of steps is based on the following concept: that as each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in the sequence. The virtue of all of this is that as the design proceeds the change process is scoped down to manageable limits. At any point in the design process after the requirements analysis is completed there exists a firm and closeup moving baseline to which to return in the event of unforeseen design difficulties. What we have is an effective fallback position that tends to maximize the extent of early work that is salvageable."

http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...

Re: Iterative development: the secret to great product launches

#50
post #44

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…

> What if "throw shit at the wall and see what sticks" really is a better way of making software than "engineering"?

What if it isn't.

Post reply on HN