When we (developers) are developing Software, our goal is often to deliver a set of features that different users of our Software need. This is what the business focuses on – whether the features have been delivered – and as such other necessary things such as ensuring that code quality is good gets low priority. This is an attempt to capture other goals in a way that business understands.
1. As a business, we need to avoid an unrecoverable disaster or one that will be very expensive to recover from in order to survive.
There are stories of companies that have gone bankrupt because of some technical failure. A classic example is Knight Capital group – a company that lost over $400 million dollars in one night because of a technical failure. http://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/. Bloomberg reported the same story.
While this failure could be largely attributed to a DevOps failure, that is not the only kind of failure that can have such a dramatic consequence. As the writer asks, why did they have code in their code base that they had not used for eight years? The first comment on that article (up-voted 28 times) was: “Yes, DevOps would have helped here, but sound coding practices would have prevented it entirely. Never re-purpose a variable.”
2. As a business we want to avoid losing customers because of bugs as we work to attract more customers.
When we deploy a product, we often get to know that there is a problem when either a member or associate of the team faces an issue or a customer contacts support. However, most customers do not complain, they simply walk away.
“But we know from consumer research that for every complaint such as Mr. Shelton’s, there are 20 or more customers who leave quietly and unnoticed and thereby provide the organization with no opportunity to learn from its mistakes.” (Harvard Business Review, https://hbr.org/1990/05/the-case-of-the-complaining-customer)
The statistics is probably grimmer with online services, especially those, in a very competitive market. How many customers may be walking away because they tried something, it did not work and they did not care to follow up?
3. As a business, we need to avoid needing to rebuild systems from scratch all the time to improve efficiency and speed up delivery.
A software is as good as it’s ability to change to meet changing requirements. Too often because we want to ‘produce’ faster, we pay little attention to this aspect only for us to get stuck in the future. When that happens, the only option is to rebuild the entire system.
In order to build faster, we do not dig a very deep foundation. After adding two stories we are at our limit and the only way to add another storey is to rebuild the entire system. With Software, it is possible to be digging the foundation deeper as we build up. Too often, we do not do that because the foundation unlike the actual building is not ‘visible’.
4. As a business, we need to avoid misconceptions about developer rate in order to plan properly.
A developer takes two weeks to develop an application. It takes another two weeks until all testing is done and bugs are fixed. Then, when the application goes live, bugs are found which take another 3 days to fix. The actual delivery rate is 4 weeks and 3 days; not 2 weeks.
5. As a business, we want to ensure that ‘temporary’ employees can contribute meaningfully to mainstream projects in order to benefit from our investment in hiring them.
‘Temporary’ employees do not stay in a company very long and as such it is important that the work they do can be easily continued by other employees. Without that, the work they do ends up as waste.
6. As a business, we want to ensure that we can make changes to our live application in 1 day in order to be able to add emergency features or ‘fixes’ or, even, just deliver new value quickly.
7. As a business, we want to cut down repetitive tasks involved in testing and deployment in order to be more productive.
8. As a business, we want to ensure that our project teams can deliver quality and reliable software with limited or no external supervision (i.e. from outside the team).