‘Not My Problem’: A Big Problem for DevOps Teams

Reposted from: ‘Not My Problem’: A Big Problem for DevOps Teams – DevOps.com

Not my problem (NMP) — (n)

1. a statement, or position, of apathy expressed by those who perceive they are external and unaffected by a negative predicament. While sometimes warranted, it is typically uttered by those who perceive themselves as powerless; can’t be bothered; are too lazy, or are selfish non-contributing leeches. See also “complete cop out.”

2. an attitude that will stymie attempts to implement DevOps in your organization and will thwart success

3. (archaic) Actually not your problem

While perhaps it’s become more frequent in our culture of relative indifference, some of our oldest stories bear witness to how timeless the phenomenon “not my problem” is. For example, in the biblical story of Cain murdering Abel, God asks Cain afterward, “Hey Cain, I can’t find Able. Do you know where he is?” Cain responds famously, “Am I my brother’s keeper? (NMP)” It crosses country borders and language barriers, too: A transliteration of the same sentiment in Polish is, “Not my circus, not my monkeys.”

Planned Obsolescence in Software

“Fast, Cheap, Good – pick two!”

In any software project (or probably any project where you are creating something), you cannot lock down all three of these dimensions–i.e., you cannot define what you want for all of them. If you are very experienced, realistic, and have control of all external factors, you might get close. For most projects to succeed, one of these dimensions needs to be more relaxed than the others.

Fast and Good

The usual expectation is that “fast and good” won’t be cheap. Lots of people or money will be needed. But lots of people does not mean it will be done fast (see the book “The Mythical Man-Month”). So part of the solution is usually bought instead of created. That gets it done fast. But will it really be good? Maybe if you spend a lot of money, to buy something really good–essentially, you’re paying for the time that others spent on it at another company. This also assumes the part you buy will be exactly what you want.

Good and Cheap

The expectation is that a “good and cheap” solution will take a long time–that one person working on a project for a long time will be cheaper than lots of people. But will it really be good? Usually, it takes more than one person to make things good. For example reviews, proofreading, and brainstorming requires at least two people. So a few people over a long time could make a good product, but that doesn’t sound like it will be all that cheap (unless the people work for free).

Fast and Cheap

“Fast and cheap” is not likely to be good. And that is the usual way projects are started. The project gets accepted by most companies when those paying for it are convinced that it can be done fast and cheap. The assumption is that it will need to be just good enough for customers to want to buy it.

Cost, Features, Quality

But let’s break the discussion across slightly different dimensions, because “fast-cheap-good” may be a fun quip, but most product and project discussions revolve around Cost, Features, and Quality.

What is this blog about?

See: About