Delivery-Driven Development: A Sure Way to Achieve Great Results

The motivation for defining Delivery-Driven Development is a lack of focus on the most important part of software development in all other DD's, in my mind. The most important thing is delivering value to the end customers, which is achieved by reaching production with our software. Most DDs have this as a side goal, while it always has to be a primary goal of any software development.

There are 4 rules in Production/Delivery Driven Development:

• Rule 1 - Deliver to production as fast as possible.
• Rule 2 - Quality matters from user's point of view.
• Rule 3 - Iterate as often as possible.
• Rule 4 - Create a product with a tailored approach.

Let us look now look at this rules in more details.

Rule 1: We Must Reach Production and Deliver Value as Fast as Possible

One thing that is unfortunately overlooked over and over again is that most important objective is delivering value to end users by reaching production.

No one cares what programming language, framework, or library we used. No one cares how cool the algorithm we wrote is or if we have unit tests or not, or if we are using TDD or BDD or none of them, or if we are using Scrum or waterfall or neither of them. If we don't deliver the value or reach the production nothing matters.

Reaching production is everything, and it should be reached as fast as possible. Going to production need to be our focus at all time.

What fast as possible means differs from use case to use case. Creating a bank or a chat program comes with a different understanding of what can and can't be tolerated, from performance to security and other points of view. We need to take context into account when we decide on a sustainable but quick release.

You might ask yourself why reaching production is so important. Only by reaching production can we validate if what we built is good or not, if users like it or not, and how it behaves when users interact with it. Only in production we can validate all our assumptions that we had while building software. Nothing else can give us answers to this questions with 100% certainty.

Reaching production fast matters, because if we reach it late, we can find out that someone has already beaten us to it, and took the whole market share. We can also find out, when we reach production, that we need to change a lot of things. If it took us a long time to get there and we might be out of the time and money to make the necessary changes.

Sometimes people think that if they do "Scrum" or "Agile," that this is good enough and that it is a done deal. If we don't push our code to production fast, nothing else matters. It isn't about methodology, it is about mindset and what we are focused on.

We must either reach production as fast as possible or prepare ourselves for failure.

Rule 2: We Must Have a Good Enough Product in Production from the Users' Point of View

If we manage to reach production very fast, but everything is crashing all the time, well we just killed our product.

Reaching production matters a lot, however, it also needs to be of decent quality from the user's point of view. If everything is exploding in our systems, but users are not aware of it, all is still good. Quality means different things from a context point of view. If users are interested in temperature or humidity, their expectations will differ from a situation when they are transferring money using online services.

We need to know how our product is behaving in production with real users, and if this is good enough or not. Keep in mind that good enough is the name of the game, we should aim to be better than anyone else in the same field, not to be perfect. This is a subtle difference, but an important one. We shouldn't sacrifice speed of delivery and everything else, just so that we can make sure that everything is perfect at all time. In the majority of cases, perfect isn't a requirement, so challenge it if it is put on the table, and question what perfect means in that case and context.

In most cases if users see some error from time to time they will be ok with it, they will refresh page, or view it in the mobile app, or maybe wouldn't even notice it.

Of course, context does matter a lot here, so don't take this is a general rule, and adapt what quality means according to the situation at hand.

Rule 3: We Must Iterate Over Our Product as Often as Possible, Keep Evolving It, and Keep Improving It.

Once you reach production, the game hasn't ended, it has just started. Keep this in mind.

We must continue iterating and evolving our product, making it better, reaching more customers, and  adding new features. We need to do this as often as possible and as quikcly as possible. Once we hit production we will start getting real feedback from users and their behavior, we will see which parts are good, what needs to be optimized, modified, or removed altogether, and which parts need to be added in order to meet users demands.

Of course, "fast as possible" will mean something different depending on the context at hand, issues or limitations that we might be facing. If, for example, we are having a lot of issues, we should deal with them first and then concentrate on evolving our platform, or we might end up in an even worse situation.

One thing to remember is that the world is constantly moving; even if we are number one today, that doesn't mean that we will be number one tomorrow, or even relevant. We need to make sure to take user feedback into account and iterate over our solution as fast as possible, and make sure that we are on top of things at all time, or we might end up in a bad situation very fast.

We not only need to reach production, but we also need to make sure we stay there and focus on it in the things we do, in the present and future.

Rule 4: Adopt a Tailored Approach According to The Problem at Hand

Very often people want to have the ultimate solution that will fit all use cases. Let us be honest, products differ, use cases differ, teams differ, context differs, technologies differ. We should take this into account when deciding on a course of action. Personally, I believe that using the same approach for every problem, or trying to find one solution to fit them all, is a bad idea which is doomed to fail. Something might work perfectly in one case, but be terrible in other. We should be aware of this and know what works when, and when it won't work, everything has limitations.

By taking all this into account, it should come as no surprise that in delivery-driven development there isn't one solution that fits all use cases. Depending on the team, the product that is being built, and other circumstances, we will be using or combining different things and approaches to achieve the end result that we are aiming for in the timeframe that we are aiming for. We might use TDD, BDD, or some other approach, or we can use only parts of it at some point in time, while ignoring them during other times. We might use Scrum or Kanban, or none of the above. There are a lot of choices to make and we should be aware of how they fit the bigger picture before deciding upon them and investing in them. Also, the important thing is not to set anything in stone; if we try something and it doesn't work, modify it and validate.

We should take our strong points into account and build upon them, while being aware of our weaker points and choosing things that will help us overcome them or keep them in check. We also need to be aware of any limitations at all time, like infrastructure that can be used or not, in regulations that should be taken into account, and so on.

It really matters what is built, who built it, and under which circumstances. There are some general guidelines that can be followed, however, much of it really depends on a lot of variables, which will in most cases be very different from situation to situation. We should look at all best practices and see which fits best with our use case and which don't.

For example, if we are building a social application, we will probably need to be extremely nimble and fast in execution, while stability probably shouldn't be our number one priority as long as it isn't too bad. If we have a million users and 0.1 % of them get an error from time to time, maybe once per day, should we care? In most cases, they will just hit refresh and all will be well. If they are getting errors too often, then we should fix it, but no errors 100% of the time isn't needed in this case.

On the other hand, if we are developing software for banks or nuclear power plants, errors might be much more costly, so we should do our best not to have them.