Code Less, Think More… Incrementally!
View original- current
Summary (TL;DR)
Incremental delivery means breaking a big project into small, useful pieces and delivering them one at a time. This approach handles changing requirements better than building the full solution upfront. It focuses on delivering value early, even if the final product takes more steps. The article uses the example of building a car: one approach builds parts of a car (wheel, chassis) and fails when the user changes their mind, while the incremental approach starts with a skateboard and evolves into a convertible, letting the user adjust along the way. Another example shows calculating crypto trade profit with a simple function instead of a full website. Key lessons: code less, think more, and tackle the problem not the solution.
Code Less, Think More… Incrementally!
Last time I wrote about Continuous Integration: A Merge Story. The post describes how a 6 months project failed because it didn't implement the principles of Continuous Integration.
In retrospect, there are a couple of things that could have been done differently:
- Integrate code changes to everyone else's work as soon as possible, preferably many times a day.
- Code less, think more.
But how to do that?
There is a fundamental challenge everybody has to deal with in a software project:
Shit is gonna change
How can you continuously integrate a project every day if it has to take months not days to finish?
If all the possible solutions to a question don't lead to a viable answer, your only alternative is to change the question.
Instead of asking "how can I build a big project?", you should ask "how can I split a big project in a way where I can build the smallest useful piece of it?"
Incremental Delivery is the idea of looking at different ways to solve a problem. It aims to deliver the big project in small increments instead of aiming straight at the final big thing.
This famous cartoon summarizes it very well:
A few things are not obvious from this cartoon.
In the first example, the final car is a non-convertible. The reason is that the user was married when she and her husband requested the car to be built. They wanted a closed car. However, in the middle of development, the user got divorced and changed their mind. They wanted a convertible instead.
The developers of the first example already started with the full picture of the "big project." The wheel was built specifically for a non-convertible model and there was no possibility for a change in the middle. The user got what they asked for, even though it’s not what they wanted.
In the end, the user is "just" happy.
In the second example, because it tackled the problem of moving faster, not the solution of having a car, there were many possibilities for changes throughout the process. The developers built a convertible car in reaction to the unexpected end of the marriage. In the end, the user gained the power to change what they wanted which is different than what they asked for.
They're happier.
The best way to deal with things that can change is to develop the minimum of what you need right now instead of speculating on whatever you may need later.
There's another thing that's not obvious.
It took 4 steps to build the car in the first example. However, in the bottom example, it took 5 steps to come up with the convertible.
Incremental Delivery doesn’t make you really "faster." If you consider the technical aspects of "speed" as the amount of stuff you’ve done in less time, Incremental Delivery can actually take more time to finish the whole thing!
However, if you consider "speed" as the amount of value you have delivered, then it’s totally possible you’ll take more time to do something but less time to finish! The trick is to build the minimum viable piece of stuff that can make the user happy, even if it’s not the final “big project.”
What people want will change and the original request will become obsolete. Or as I said before:
Shit is gonna change.
The only thing you can do is to accept that fact from the start and plan accordingly.
Don't try to change the world, surf on it.
Incremental Delivery tackles the problem, not the solution, and that allows you to work less and be faster.
In the convertible example, the developers didn’t need to know what the user wanted. They aimed to improve the solution for the problem along the way, albeit always in the right direction.
Note: You can argue the cartoon is a bad example that doesn’t fit reality for many reasons… and you’re right! See this response for more details.
This principle can be applied to almost any piece of work, not just user-facing product development.
When you always code something small, you can discover new information that may change your vision of the "big task" you have to do. It's also a way to avoid doing more than what's necessary and accommodate changes in your own understanding of the problem.
Let’s say you joined the cryptocurrency bandwagon and started some buy/sell operations in a couple of Exchanges, however, those exchanges don't allow you to clearly see the profit/loss from your current and future sales.
You can build a website.
The website will connect to the API of all the exchanges you use and provide charts. The charts will show how much profit you had from your past sales. It will also show how much you will get in profit if you sell your coins right now.
In this case, you have to build a server, host it somewhere, plan the architecture, look at some Open Source libraries for charting, a test framework, etc…
It will take a long time to build anything that works!
Or you can build a small function.
The function will return the profit from a buy/sell operation and you can run it in Chrome DevTools.
In this case, it will deliver value to you with almost no effort. It will also allow you to reuse the function in a website you may — or may not — build in the future.
You can also add a couple of console.log statements as a replacement for the "test framework". That should be enough to verify the function is working. You can even build it using TDD!
If you want to provide a better interface, you may not need a server. You can create an HTML file with a couple of text inputs and run it locally from the file system.
When you really need to, start a static server and just copy the HTML.
You can’t build a bridge incrementally, but there are many ways of looking at the problem of crossing the river.
The essay “The Cathedral and the Bazaar” showed Incremental Delivery being used in Open Source. It was used on the development of Linux. Here’s an excerpt:
Linus was treating his users as co-developers in the most effective possible way:
7. Release early. Release often. And listen to your customers.
— An excerpt from "The Cathedral And The Bazaar,” 1999
That principle eventually found its way to the agile manifesto in the form of “satisfy the customer through the early and continuous delivery of valuable software.”
If you always start to build a big task from the beginning without incremental development in mind, you're very likely to get stuck. Even though you’re writing code, that doesn’t mean you’re creating value and being productive.
Instead of looking at the solution, look at the problem. Instead of looking at the answer, look at the question.
As engineers, we tend to measure progress as working hard. However, we need to work smarter.
And that means to code less and think more incrementally.
Make sure you're not starting with the wrong wheel…
…or you might miss the boat.
If you liked this, you might like readplace.com, built for exactly this kind of reading.
Thanks for reading. If you have some feedback, reach out to me on LinkedIn, Reddit or by replying to this post.
