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

Emil Vikström

Copyright © 2014 Emil Vikström. All Rights Reserved.

%d bloggers like this: