A couple months ago, I had the privilege of keynoting at PuppetConf 12. The Puppet crew put together a fantastic two days of talks, and it was a wonderful opportunity to reconnect with so many people in the DevOps tribe.
The first part of my 25 minute talk was about the downward spiral that happens in almost every IT organization, which impacts not only IT Operations, but also Development, Product Management and “the business,” which we’re all a part of. It starts with fragile applications in production, resulting in the business missing the commitments it makes to the outside world, which then results in urgent, date-driven projects put into the Development queue. This results in more fragile applications in production, and an ever increasing amount of technical debt, slowing down the organization, starving it of the ability to do productive work.
The second part of the presentation are six of my favorite prescriptive DevOps patterns, derived from the Three Ways, which we’re using to describe the principles that underpin DevOps. They are:
1. Define work and make it visible.
2. Make environments available early.
3. Wake up developers (fast feedback loops).
4. Embed Dev into Ops (quality at the source).
5. Break things early and often.
6. Reserve 20% of cycles for technical debt reduction.
You can find out more about my upcoming book “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win,” coming out on January 15, and get the whitepaper “Top 11 Things You Need To Know About DevOps” here.
Reserve 20% of cycles for technical debt reduction. –
What does this mean?
F. Yo. Couch: that means spend one day each week working to resolve the issues left in your code base in a rush to deploy to production features which were not quite ready for prime time. It might include expanding the coverage of your testing suite, automating manual deployment processes, capturing in your version control processes key artifacts not already under version control or a wide number of tasks which left untended will mount up and cost your organization in the long run. Technical debt is called debt for a reason: it costs you to service that debt, either in interest payments which do not get applied to the principal; or in extra work paying down that debt, so you get your operations back on track.