Have you worked on a larger project? Maybe something that required you to work in more than one code base or more than one package? Then you might have already encountered situations in which you needed to take a problem apart into pieces. This is by no means an easy task. And that is what makes it interesting. 😄
I'm going to assume that when you're faced with a problem you're going to split it into smaller chunks. There are lots of ways how to do this 1. While there are no wrong decisions, some might be better than the others. Because we're not solely taking a problem apart, we're looking for ways how to deliver value faster and reduce risk.
TL;DRdecrease the time-to-value for your users. When you do more you're placing bets on whether your current assumptions are right. Sometimes these bets will play out and sometimes they won't. The trick is to be aware of the risks you're taking.. I believe you should always do as much as needed and as little as possible to get the current task done. By doing this you
Especially when you're creating something new and you want to test out ideas you need to make sure that you're not wasting time on the non-essential parts.
Deliver value fasterPareto principle. According to it, you're going to build 80% of a feature in 20% of the time. Vice versa this means that 80% of your time is required to build the last 20% of the feature.. At the same time, you might have heard about the
I got a couple of questions for you.
- Is the real customer value in the last 20%
- If yes: Why didn't you start with them?
- If no: Why let the customer wait?
Ask yourself "Why would I let my customer wait 80% of the time if the good part of a feature is already done?" I'm pretty certain that the first 80% include useful functionality. If we release these features once they are ready we can help our customers faster.