
Iterative development: the secret to great product launches - maxchurilov
https://www.mindk.com/blog/iterative-development/
======
lbacaj
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. That culture is set, I say this having seen it
first hand.

As an example, and a little self promotion that I hope I won’t get downvoted
for :) I have been working on a cross platform App that reads any article to
you. It uses AI/ML models to convert the text to audio so you can listen on
the go and maximize learning on that dead time on commutes.

This is a fairly complex thing to build, especially in a few months and to
make it work cross platform. We now have a lot of features but this all
happened feature by feature. Get one thing done, get it out, start on the next
thing. If I tried this approach in a big team at a big company there is
absolutely no way we would have this much done in a few months. The politics,
the nonsense, etc.

If you want to check out the app you can try it here:

[https://articulu.com](https://articulu.com)

~~~
chooseaname
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..."

~~~
mattnewton
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-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

------
nadam
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 become oversaturated, because everyone
wants to start a product with a 1 month MVP development. So you will have a
competitive advantage if you are able to design products in problem spaces
where even the MVP is relatively big, so you can attack not-so-oversaturated
markets. I think the ability to design complex products becomes an important
skill.

~~~
tachyonbeam
> 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.

~~~
rangersanger
Completely agree with this. Previously I was a PM at a rather large (valued
>1bn) sales software organization. I was tasked with building a completely new
product to replace the original product. We built an MVP and had our internal
sales team use it. It wasn't easy, it took some motivation to get them to use
it over the large, steady, enterprise solution they were used to. But, they
used it enough that we received considerable feedback that we rolled into the
public beta, which was much bigger than an MVP.

------
bigpicture
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 to go backwards only that specific piece
did so while everything else continued as normal. Unit testing, integration
testing, system testing, etc was all present on day 1.

~~~
igouy
> 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...](http://www-
scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf)

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

~~~
braythwayt
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 the ideal
plan never works out as originally envisioned, whether we tried to develop
sequentially or not.

But the “ideal” plan is often like highly optimized code: Expensive to change.
So it has its own cost that cannot be escaped. So I am left extremely cynical
about the “ideal sequential development” approach.

It always seems at the outset to be cheaper and faster, but ends up being
expensive and inflexible.

JM2C.

——

Now if you want something REALLY expensive, I give you “Scrumfall,” a plan
where you combine the costs of iterative development with the inflexibility
and attendant costs of fixed date, fixed scope, and attempt to optimize
sequential development.

But hey, you get to wear an “agile” badge, even though “inspect and adapt” has
no place in the process.

~~~
kabouseng
“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.

~~~
smokey_jomo
As someone living in a housing development that’s being built around them,
this isn’t true in the case I see.

2 important reasons are: 1) the project is around 6 years in total 2) the
company has to fix any issues with the house for the first 2 years.

If they did all the foundations first, they’d have exactly the problem
described in the article - no money till right at the end. Instead, they get
money the entire way along and use that to finance the rest of the project.
This isn’t an optimisation, iterative delivery is essential to their viability
as a business.

They also eat the support costs on houses they build. That means they are
repeatedly changing “features” in the houses to minimise those support costs.
Just walking down 1 street you can see the evolution of the houses over time
as they fixed various small issues with the original design. The houses look
basically the same to a casual observer, but are quite stark to someone who
lives in one of the versions. They are very obviously agile, and have a great
system for inspecting and adapting. That doesnt happen on 2 week cycles, but
it does happen at a pace appropriate for them.

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

~~~
lmm
> 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.

~~~
shadowtree
"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).

~~~
lmm
> 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?

~~~
igouy
> 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.

~~~
lmm
If it isn't, then maybe agile is a bad idea and we should expect to see agile
projects fail more often/expensively than non-agile projects. But that's not
what we see (at least not what I've seen).

------
hamilyon2
Well, isn't iterative development and small batches established and well-known
state of art? Am I missing something?

~~~
petard
Maybe not so much outside the HN bubble but I don't understand what makes this
article different from the other zillion agile articles either.

~~~
Sujan
"Content Marketing"

------
dfilppi
Iterative is the key insight ( and main value ) of methodologies such as Agile
and XP. It is essential in projects where fantastically detailed requirements
aren't known in advance (i.e. any non-trivial project).

------
marcus_holmes
Is it me, or is "a series of small waterfalls" like TFA describes not actually
anything to do with Agile?

I mean, I guess it's more agile than one big waterfall, but it's still not
embracing the principles of Agile (like involving developers in product
decisions, or letting developers assign deadlines). It's still locked in the
worldview of "serious people spec the product, then the nerds push the
nerdbuttons to build it".

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

~~~
Celarnor
Did it ever mean something else? :P

------
mpweiher
"When to Use Iterative Development

You should use iterative development only on projects that you want to
succeed."

\-- Martin Fowler, UML Distilled

------
baybal2
> 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, and your
business activities - a lot of people there mistake the two.

~~~
AlexTWithBeard
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.

~~~
crispyambulance

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

It really depends on which industry you're talking about. I remember somewhere
reading about "emergent" and "convergent" industries.

Many mature industries like commercial aircraft manufacturing are "convergent"
meaning that their goal is providing the customer what they're expecting.
Success is measured by "meeting the spec", beating the competition using some
combination of price, reliability, time-to-market, and leveraging established
status and reputation in the market. I think your SW development analogy of
version control branches applies to convergent industries.

There are other industries which are "emergent." These types of industries
attempt to create markets with entirely new and unexpected products. They
don't face competition, instead their success hinges on developing the market
for the product.

The rules are entirely different for each of these two categories.

------
omouse
Biggest missing piece here is what drives the plan and the development.
Delivering value? How is the value defined and where's that coming from?
Customer surveys every few months? Number of clicks on a feature or page?

Can't have a great product launch without understanding the customer and that
includes acquiring them through sales & marketing. Iterative development is
almost a given at this point.

------
npollock
Another under-appreciated fact: at iteration 1 you have very little data from
feedback, at iteration 10 you've hopefully got a lot more - an iterative style
of product development gets easier and more efficient as time/iterations
increase

------
platz
Making the Roadmap agile is quite difficult in some orgs.

Also, there are budgeting committees that tend not to think of themselves as
agile, or take kindly to being told what to do or how to operate, and they put
constraints on the whole thing.

------
anilakar
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?

~~~
mikekchar
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](http://wiki.c2.com/?HistoryOfIterative)
[2] -
[https://en.wikipedia.org/wiki/Spiral_model](https://en.wikipedia.org/wiki/Spiral_model)
[3] -
[https://en.wikipedia.org/wiki/Rapid_application_development](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...](https://books.google.co.jp/books/about/Object_oriented_Software_Development.html?id=mJ9QAAAAMAAJ&redir_esc=y)

------
maksimpiriyev
there is specific term for that , pipeline

