Production Driven Development a.k.a. Delivery Driven Development sure way to achive great results
Motivation for defining Production/Delivery Driven Development is lack of focus on most important part of software development in all other DD’s, in my mind. Most important thing is delivering value to end customers, which is achieved by reaching production with our software. Most DDs have this as a side goal, while it always have to be primary goal of any software development.
There are 4 rules in Production/Delivery Driven Development
- Rule 0 – deliver to production as fast as possible
- Rule 1 – quality matters from user point of view
- Rule 2 – iterate as often as possible
- Rule 3 – tailored approach
Let us look now look at this rules in more details.
Rule 0 – we must reach production as fast as possible, deliver value as fast as possible
One thing, that is unfortunately overlooked over and over again is, that most important thing is delivering value to end users by reaching production.
No one cares what programing language, framework or library we used. No one cares how cool algorithm we wrote 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 none 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, differ from use case to use case. Creating a bank or a chat program comes with different understanding of what can and can’t be tolerated, from performance, security and other points of view. We need to take context into account, when we decide on the speed at hand.
You might ask your self why is reaching production so important. Only by reaching production we can 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 took along while building software. Nothing else can give us answers to this questions with 100% guaranty.
Reaching production fast matter, because if we reach it late, we can find out, that someone has already beaten us to it, and took 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 long time to get there, we might be out of the time and budget to make necessary changes.
Sometimes people think that if they do “Scrum” or “Agile” that this is good enough and that it is done deal. No, it isn’t, if we don’t push our code to production fast, nothing else matters. It isn’t about methodology, it is about mind set and what we are focused on.
We must either reach production as fast as possible or prepare ourself for failure.
Rule 1 – quality matters, we must have good enough product at all time in production from 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 need to be of decent quality from user 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 context point of view. If users are interested in temperature or humidity, their expectations will differ from 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 then anyone else in same field, not to be perfect. This is subtle difference, but important one. We shouldn’t sacrifice speed of delivery and everything else, just so that we can make sure that all is perfect at all time. In majority of cases perfect isn’t requirement, so challenge it if it is put on the table, and 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 in 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 2 – we must iterate over our product as often as possible, keep evolving it, and improving it
Once you reach production, 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, adding new features. We need to do this as often as possible and as fast as possible. Once we hit production we will start getting real feedback from users and their behavior, we will see which parts are good, which need to be optimized, modified or removed all together, and which parts need to be added in order to meet users demands.
Of course, fast as possible will mean 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 even worse situation.
One thing to remember is that world is on constant move, 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 bad situation very fast.
We not only need to reach production, but we also need to make sure that stay there and have focus on it in the things we do, current state and future.
Rule 3 – tailored approach according to the problem at hand, team that will deliver and circumstances involved
Very often people want to have ultimate solution that will fit all use-cases. Let us be honest, products differ, use-cases differ, team differ, context differ, technologies differ. We should take this into account when deciding on 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 wrong idea which is doomed to fail. Something might work perfect 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 a surprise that in case of production/delivery driven development there isn’t one solution that fits all use-cases. Depending on team, product that is being built and other circumstances we will be using or combining different things and approaches to achieve end result that we are aiming for in time frame that we are aiming for. We might use TDD, or 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 how they fit the bigger picture before deciding upon them and investing into them. Also, important thing is not to set thing 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 be aware of our weak points and chose things that will help us overcome them or keep them in check. We also need to be aware of any limitations at all time, for example of infra that can be used or not, in regulations that should be taken into account and so on.
It really matters what is build, who build it and under which circumstances. There are some general guidelines that can be followed, however how much really depend from 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 fit good with our use case and which don’t and we would already be on a good way
For example if we are building social application or something like that, 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 1 million users and 0.1 % of them might get error from time to time, let say once per day, should we care. In most cases they will just hit refresh and all will be good. If they are getting errors to often, well than we should fix it, but 0 errors 100% of time isn’t needed in this case.
On other hand if we are developing software for banks or nuclear power plants, well in that case errors might be much more costly, so we should do our best not to have them.
Summary and where to go next
If you would like to know more about all of this and how to achieve this, feel free to contact me or look out for my future posts on this subject and some of the best practices
Published on Java Code Geeks with permission by Vladimir Dejanović, partner at our JCG program. See the original article here: Production Driven Development a.k.a. Delivery Driven Development sure way to achive great results Opinions expressed by Java Code Geeks contributors are their own. |
