Live data from Hacker News

Iterative development: the secret to great product launches

mindk.com

11–20 of 77 posts

Re: Iterative development: the secret to great product launches

#11

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…

“Scrumfall” - Sounds fun /s

>> So I am left extremely cynical about the “ideal sequential development”

Off course, in development/engineering work that has unknowns. But taking TFA example of building houses, most / all developers would do the foundations of all the houses first before moving on i.e. working sequentially.

Re: Iterative development: the secret to great product launches

#12

Earlier quoted context omitted.

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…

“Scrumfall” - Sounds fun /s >> So I am left extremely cynical about the “ideal sequential development” Off course, in development/engineering work that has unknowns. But taking TFA example of building houses, most / all developers would do the foundations of all the houses first before moving on i.e. working sequentially.

I have zero to say about TFA’s example, as it is discussing iterating over releases of a longer scale than most people are thinking of when arguing sequential versus iterative development.

In my environment, we “inspect and adapt” every two weeks, and we tend to do marketing launches a couple of times a year.

But SpaceX was not launching rockets into space every two weeks, so their “iterations” from the outside look more like most companies’ product launches, not like sprints or whatever people call their iterations that happen on a fortnightly or monthly scale.

Re: Iterative development: the secret to great product launches

#13
I don't understand why Risk Management isn't a thing anymore. Reducing risk at cost of reducing quality of a product is not generating a "great product". It's great for reducing risk for investment. So, the "secret" lies beneath the actual product - quicker return of investment. That's what agile actually means now. Great.

Re: Iterative development: the secret to great product launches

#14
post #9

According to my SW engineering study books, iterative development is redesigning the whole product from the beginning to add new features. Surely the author meant more agile methods?

I'm curious which books those are. The C2 wiki has an interesting history of iterative development[1]. I got introduced to iterative development around 1993 (relatively late! ;-) ). There was a great book from someone who was originally from IBM. I can't remember the author, but I think his first name was Mark (Hey, this is HN, someone will remember...) Even Barry Boehm's Spiral model doesn't redesign the whole thing from scratch [2]. James Martin's RAD (Rapid Application Development) process does kind of do that in an interesting way (I think). Now I'm going to embarrass myself here, but from what I remember (this is a long time ago!) I think the idea was to do rapid prototypes in each iteration. However (and this is the cool part), you add to a reuse library in each iteration. The idea being that you want to build all the tools that will allow you to rapidly build the prototype for the next iteration. I've always wanted to try it, but have never gotten around to it. Wikipedia page here [3] (but I suspect it doesn't match my remembering... which leaves me wondering what I'm remembering...)

Anyway, there were lots and lots of iterative processes before Agile was even being imagined. I'm surprised that there are software engineering books that don't realise this...

[1] - http://wiki.c2.com/?HistoryOfIterative [2] - https://en.wikipedia.org/wiki/Spiral_model [3] - https://en.wikipedia.org/wiki/Rapid_application_development

I remembered. The author is Mark Lorenz. Book is here: https://books.google.co.jp/books/about/Object_oriented_Softw...

Re: Iterative development: the secret to great product launches

#15
post #7

> Iterative development: the secret to great product launches I'd argue that often far from being helpful. Some of the best tech bosses I worked under would've shove a person out of the window simply for uttering a word "iteration." One told about that approach as - "trying to construct an airplane by making changes utill it stops crashing on takeoff" It a good to have a distinction in between software being iterated…

Isn't it how first airplanes were built?

First let's build something that flies.

Now let's build something that can fly for more than a minute.

Now let's build something that flies for more than a minute and can also be steered.

It's pretty much the same nowadays: engineers keep building new generations of airplanes which are heavily tested snapshots of current "trunk" branch.

Re: Iterative development: the secret to great product launches

#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" resources working in a different country.

Re: Iterative development: the secret to great product launches

#17
post #7

> Iterative development: the secret to great product launches I'd argue that often far from being helpful. Some of the best tech bosses I worked under would've shove a person out of the window simply for uttering a word "iteration." One told about that approach as - "trying to construct an airplane by making changes utill it stops crashing on takeoff" It a good to have a distinction in between software being iterated…

Isn't it how first airplanes were built? First let's build something that flies. Now let's build something that can fly for more than a minute. Now let's build something that flies for more than a minute and can also be steered. It's pretty much the same nowadays: engineers keep building new generations of airplanes which are heavily tested snapshots of current "trunk" branch.

[deleted]

Re: Iterative development: the secret to great product launches

#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 not to have one.

As the quote goes: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

You can, and should, have specifications for the next ~two weeks of changes that you want to do. These should be verifiable at a user-facing level. But after that you iterate. Trying to specify further in advance or at more detail than what's user-visible is a recipe for disaster.

Re: Iterative development: the secret to great product launches

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

> You can, and should, have specifications for the next ~two weeks of changes that you want to do.

We completely agree here - are you saying you've never encountered the "we're agile, no need for specs" mindset?

Re: Iterative development: the secret to great product launches

#20

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…

At my employer I think we have a patent of scrummerfall. Or as I like to call it, waterfolly. We have to make detailed user story level estimates a year in advance, create capital requests to be budgeted with precise deadlines and staff based on numbers in spreadsheets, and call ourselves agile. Of course it never works yet we use our agile mindset to find some excuse to blame it on.
Post reply on HN