DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DataOps
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • Techstrong.tv Podcast
    • Techstrong.tv Video Podcast
    • Techstrong.tv - Twitch
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Content
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Techstrong TV
    • Techstrong.tv Podcast
    • Techstrong.tv Video Podcast
    • Techstrong.tv - Twitch
  • Media Kit
  • About
  • Sponsor
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DataOps
  • DevSecOps
  • DevOps Onramp
  • Platform Engineering
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps
    • ROELBOB

Home » Blogs » Doin' DevOps » Time and complexity; or, Why are some things hard to do?

Time and complexity; or, Why are some things hard to do?

Avatar photoBy: Greg Pollock on September 22, 2014 Leave a Comment

Why are some things hard to do? If we want to make complicated tasks easier, which is one of the goals of DevOps, we need to have some theory of why they are difficult in the first place.

Recent Posts By Greg Pollock
  • Config Management & F***ing Shell Scripts
Avatar photo More from Greg Pollock
Related Posts
  • Time and complexity; or, Why are some things hard to do?
  • DevOps’ weakness and what it does best
  • DevOps Lessons from the Dyn Attack Fiasco
    Related Categories
  • Blogs
  • Doin' DevOps
    Related Topics
  • automation
Show more
Show less

Richard Garfield, a mathematician and game designer, presents two factors that make tasks more difficult: time constraints and complexity. Our ability to solve a problem depends on the amount of time we can spend working on it and the complexity of the problem.

TechStrong Con 2023Sponsorships Available

Time and Difficulty

DevOps discussions generally focus on time as the relevant dimension. Business value is measured in time: time to market, time to recover, and lead time for change are all important metrics for DevOps. Doing the same amount of work in a smaller amount of time is better. But an emphasis on time can also be misleading. Allotting less time for a task isn’t the same as truly being faster.

So what makes something take more or less time? Part of the difficulty of a task is relative to the person doing it. Provisioning a new server might be straightforward for an administrator, challenging for an application developer, and impossible for a graphic designer. Hiring good people and matching them with the right tasks reduces the difficulty of the task and the time required to complete it.

Complexity and Difficulty

But regardless of who’s doing it, the task to be done is the same. The specifications have an objective existence outside of whatever person is doing the work. The objective part of a task’s difficulty is its complexity.

The parallel between time and complexity is evident in the thought experiment Richard Garfield proposes. Imagine you are standing in front of two doors. One has a dragon behind it, the other has treasure. Each door is printed with a math problem that reveals whether the door contains a dragon or treasure. If you have a very short amount of time to decide, you will only be able to solve a fairly simple problem before being forced to guess which door is safe. Similarly, if you have a lot of time but must solve a very complex problem, you will again be reduced to guessing. Either insufficient time or excessive complexity can force a person to guess in a situation where a knowable answer exists.

Automation and Complexity

DevOps typically aims to reduce complexity through the “automation” leg of the CAMS definition. Now that we have examined the problem more broadly it’s clear that automation is a subset of the class of “things that reduce complexity.” Before automating, or if automation efforts at your organization have yielded disappointing results, a good check would be to ask “will this reduce the complexity of deploying code?”

Automating without visibility into what/how you are automating will move complexity around but it won’t reduce it. You’ll be able to spin up new builds really quickly—once you’ve tracked down the person who pushed the latest version and forgot to mention the three little configuration settings you need to change for it to work. Configuration drift or pockets of automation reintroduce complexity. Without visibility and monitoring, these problems grow on automation systems like mold on untended fruit.

This is not to say that automation is bad. When done in a mature environment with testing and visibility, automation is the greatest tool for reducing complexity. But without independent validation and monitoring, you’ll find that automation can also be one of the biggest sources of complexity.

Filed Under: Blogs, Doin' DevOps Tagged With: automation

« Top 3 must-haves in Dev/Ops project handoffs, Part one
JumpCloud launches new Directory-as-a-Service offering »

Techstrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Evolution of Transactional Databases
Monday, January 30, 2023 - 3:00 pm EST
Moving Beyond SBOMs to Secure the Software Supply Chain
Tuesday, January 31, 2023 - 11:00 am EST
Achieving Complete Visibility in IT Operations, Analytics, and Security
Wednesday, February 1, 2023 - 11:00 am EST

Sponsored Content

The Google Cloud DevOps Awards: Apply Now!

January 10, 2023 | Brenna Washington

Codenotary Extends Dynamic SBOM Reach to Serverless Computing Platforms

December 9, 2022 | Mike Vizard

Why a Low-Code Platform Should Have Pro-Code Capabilities

March 24, 2021 | Andrew Manby

AWS Well-Architected Framework Elevates Agility

December 17, 2020 | JT Giri

Practical Approaches to Long-Term Cloud-Native Security

December 5, 2019 | Chris Tozzi

Latest from DevOps.com

Stream Big, Think Bigger: Analyze Streaming Data at Scale
January 27, 2023 | Julia Brouillette
What’s Ahead for the Future of Data Streaming?
January 27, 2023 | Danica Fine
The Strategic Product Backlog: Lead, Follow, Watch and Explore
January 26, 2023 | Chad Sands
Atlassian Extends Automation Framework’s Reach
January 26, 2023 | Mike Vizard
Software Supply Chain Security Debt is Increasing: Here’s How To Pay It Off
January 26, 2023 | Bill Doerrfeld

TSTV Podcast

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays

GET THE TOP STORIES OF THE WEEK

Most Read on DevOps.com

What DevOps Needs to Know About ChatGPT
January 24, 2023 | John Willis
Microsoft Outage Outrage: Was it BGP or DNS?
January 25, 2023 | Richi Jennings
Five Great DevOps Job Opportunities
January 23, 2023 | Mike Vizard
Optimizing Cloud Costs for DevOps With AI-Assisted Orchestra...
January 24, 2023 | Marc Hornbeek
A DevSecOps Process for Node.js Projects
January 23, 2023 | Gilad David Maayan
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2023 ·Techstrong Group, Inc.All rights reserved.