Medium

Great question!

But in real world, you should be able to reuse all components of the car, including wheels, engine, transmission, all the most expensive stuff, to convert it into convertible. If you can’t reuse anything, something went terribly wrong, probably because a complex machine was built as monolith, instead of as a composition of many reusable components.

You’re completely right!

In the real world, if you can't reuse anything, it will take a long time to build the car in the last step of the second example. Ideally, you should thrive to reuse as much as you can from the previous product, not just the knowledge you've acquired.

There's a whole set of different techniques to handle that, but it's not the focus of this specific post.

In order to focus on the knowledge benefit, the example doesn't show the reusability benefits. That happens because maps have to sacrifice information in order to be understandable and focused.

There should be a tradeoff between the reusability and learning more what to do.

Definitely!

If you throw away everything in every iteration without reusing it, how are you able to build a car (complex, many parts), in same amount of time (single iteration), as a skateboard (simple, kid could do), starting from scratch?

I get where you’re coming from.

The cartoon doesn’t say that each step (iteration as you call it) takes the same amount of time. It’s an oversimplification of the concept focusing on the incremental approach. The step (iteration) can take more time or not.

As I said earlier, a map can’t tell everything, it has to be focused.

That doesn’t change the core idea, though.

As mentioned in the article, Incremental Delivery doesn’t make you faster as a developer. You have your speed to develop and nobody can change that. What it does is to sacrifices technical speed for perceived speed. It also allows you to get early feedback from the user so that you can learn often and earlier.

In other words, it allows you to get to the last step and know for sure what you have to build, reducing the "guessing" as much as possible. Most of the time you start building the big thing “believing” it’s what the user wants and you’ll only know at the end when the user says: sorry, that’s not what I wanted.

Starting with the car can be the wrong move in that case. It’s a journey of continuous learning, more than continuous coding.

That’s also why the conclusion is: code less, think more.

But be careful!

This technique is useful for products that have a direct impact on the user. It's also useful when you don't know what the user wants or if they're more likely to change their minds.

Let's say there's a project to make the system conform to a set of guidelines from the government.

The user is the government. You're either compliant, or you're not. You either build the car, or you don't.

Incremental Delivery blows off.

In the end, there’s no silver bullet. It's just that most new projects, like web startups, are a great fit for this type of incremental development.

Thanks for asking.