In traditional software development we often make the assumption that because of the complexity we need to configure software and production environments manually for each delivery. Unfortunately this leads to that
- We spend a long time and lots of money to configure the software for delivery
- The demotivating work makes good engineers leave
- We waste valuable resources because this complex work is done by well-paid system experts
- We get different results from tests and configuration depending on who did the job
- Engineers wants to do a good job and fixes all the problems without raising the issue, often outside work hours
When we configure the infrastructure we often make the same assumptions as when we deliver software; we don’t see the benefits with automating something that we will do different at the next delivery. This leads to lots of re-work in for example:
- We don’t know what configuration we have used and cannot trust our tests
- We have difficulty in reproducing errors
- We implement quick-fixes which leads to more problems later
This anti-pattern can create a nasty loop of behavior that is difficult to get out of because it is difficult to see any other solution.
Doing an analysis of the costs associated with the current situation, a ROI of implementing more automation or Continuous Delivery and then creating a business case is usually a good first step.
Other Anti-Patterns
- We deliver to a production-like environment only after development is done
- We have long lead-times from requirements to production
- We are not aware of where the waste is in our process
Emil Vikström
My specialities are efficiency in IT, leadership, management innovation and people development
Latest posts by Emil Vikström (see all)
- “Big 5” dangers for your software company - March 10, 2015
- How to produce successful change - November 19, 2014
- Guest blog: Stepping Stones into the Future through Leadership Agility at Ericsson - September 1, 2014
Copyright © 2014 Emil Vikström. All Rights Reserved.