Reply to post: Continuum

Happy mode, sad mode, DevOps mode: Stop worrying and go bimodal



Maybe instead of bi- or tri- or quad-modal it makes more sense to think about a continuum. At one end, when a project or idea is new, speed and ease of experimentation are paramount. So move fast and sure, go ahead and break things from time to time when you're at that stage. But if the project succeeds, people start depending on it, and stability becomes more important. If you're doing it right, there's a natural progression rather than a fixed dichotomy.

This is true even for new, disruptive businesses. In the early days of, say, Uber or Twitter or Facebook, an occasional burst of unexpected downtime was probably quite acceptable if that was the cost of rolling out new functionality at a rapid pace. But now that those companies are successful and established, they're probably much less willing to risk unplanned downtime -- service disruptions now trigger immediate snarkery from world + dog + vulture. Or think about AWS -- an occasional glitch in some new experimental / beta service is to be expected, but we expect EC2 and S3 to remain stable and reliable all the time.

So you evolve -- you use agile when it's appropriate, and you use stricter change control when that's appropriate. Different processes and standards for different stages of the project's lifecycle -- a continuum as the risks and costs and opportunities change over time.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022