Cost is one of the important corners of the Project-management triangle. This factor is especially important for decision-making from business perspective.
Let’s look at one of the techniques that will help us take more informed decisions about various operations we as developers do.
Consider a scenario when we have to automate the deployments in your project. One natural approach these days, is to automate everything. But let’s take a closer look at the things more closely.
Let’s put some numbers on a graph. On the X-axis we have the percentage of automation done in the project and on the Y-axis we have the cost needed to automate it.
Let’s put one more graph on it, that of “doing things manually”, indicated by green curve.
As it turns out, the cost of doing everything manually is too high. It would require a step-by-step manual intervention many personnel (typically Devops). So if we have 0% automation in our project, the cost of doing everything manually is quite high.
On the other hand, the cost of automating everything, every single step is also high, since doing this will take a considerable amount of time and effort for developing it. (indicated by orange curve)
However, if everything is automated, the cost of doing deployments manually tends to be zero, we can deduce this by comparing the curves.
Now let’s do something interesting. If we add the values of these 2 graphs, at every single point, we would get a curve of something like this (indicated by dotted red curve)
This red U-shaped dotted curve, indicates the total cost if the deployments are done in combination (manual and automation). As you can see the cost tends to be minimum at Point(X,Y).
We can therefore infer that you should:- “Automate X parts of the system by investing Y amount in it“.
Why is this statement important?
Simple, cost. You don’t want to overspend on one particular aspect of the project. Instead prioritize things, (which in this case is X %) and automate them first. And then if you have time, money and will, go for the remaining (100-X)%.
Find your minimum dropping point. It could be way off on either sides. But having a rough idea of where you stand, can help you optimize your business.
Please note the above curves are approximations for explanatory purposes, the actual values may vary, scenario-to-scenario, team-to-team…..
This technique can be used in many other decision-making processes, such as “How much code coverage should we have?”, “How good product quality we want?” and so on…..
The most important part in this thought process is “Prioritization”. Do not plan big upfront. Instead, go step by step. Look where you stand after regular intervals and then do course corrections accordingly. After all, that’s what “Being Agile” means….
