The Pain Curve (Part I)
Note: It’s been a long while since I’ve posted something. I could get into the details about how my family moved to a new house and how I’ve had a lot of other stuff on my plate, but I’d rather just get into something I’ve been thinking about more frequently over the last few months.
I think we can all agree that “die or do not die” is an extreme decision with consequences. I mean,…imagine all the stuff you have to do if you choose “don’t die.”
Recently, I’ve been thinking a lot about the decisions we make and how they impact us, especially the decisions we decide not to make sometimes. I think everyone agrees that decisions have consequences; as we tell our kids, sometimes there are good consequences and sometimes there are bad consequences - but decisions always lead to some sort of consequence. However, it is also true that making no decision or taking no action has consequences as well. We just don’t often think about that.
As a people, we’re very clearly wired to resist change. There’s a reason that a job change, moving, and getting married or divorced rank among life’s biggest stressors. As a species, we’re pretty bad at processing large scale changes. Heck, most of us are bad at processing small-scale changes. When we moved into our new house, we put coffee cups in one cabinet and water glasses in the other. After a week, we thought maybe we should change them and we had a mini argument about their placement - even though it had been less than a week and the actual change was a matter of feet.
Wait, wait, wait… you want me to leave the cave? I know it smells, and there’s lots of dead people in here, (those things might be related) but I’m good.
This resistance to change is likely some survival tactic in our ancestry. Maybe once we were safe in some sort of cave or something 55,000 years ago, it was much riskier to change caves than it was to just hang in the same cave our grandparents died in. Ancestors staying in the cave had a survival advantage, and so natural selection favored the change averse. Honestly, I don’t know; I’m not a paleo-archaeologist. But it’s so common among so many people in all walks of life that it’s difficult to think it’s not hard-wired in there somewhere.
Before I get into what this has to do with IT (and trust me, I’ll get there), I want to cover two specific concepts that I think are logical extensions of avoiding change that are going to be relevant as we talk more about how this impacts those of us in positions to make decisions. And just in case you’re thinking that’s not you, it absolutely is you – everyone makes decisions every day.
First, there’s the obvious option of “kicking the can down the road” when faced with a problem to solve or decision to make. This boils down to doing effectively nothing or ignoring the thing in its entirety. The biggest example of the consequences of this is that problems often compound. This is why almost every mechanic and contractor will tell you to take care of problems in your car or house ASAP, because if you don’t they have a real tendency to explode into major problems. I’m guilty of this one myself. Years ago in our first house, I had found a small spot of rotting trim board. I decided I’d take care of it the following year, and by then the rot had spread and I had to replace a whole door, sheathing, and trim for my garage. Fixing it the prior year would have just been prying off a board and nailing a new one in place.
Sometimes when deadlines are involved (explicit or implicit), you end up needing to take more drastic action in order to avoid a catastrophe. For instance, if you know at the start of the year that you need to cut your annual budget by $6000, it’s easy to see that you need to cut your spending every month by $500. But if you don’t take action right away, that number goes up over time. You still have to save the $6000, so for each month you don’t make a cut the cuts have to be deeper in the remaining months. If you wait until July to readjust your budget, you now have to cut $1000 each and every month to make the goal.
Elephants are beautiful, and endangered animals. Don’t eat them… even if you’re really hungry.
Second, there’s a temptation to not “boil the ocean” and tackle some problems (especially large ones) slowly. The old joke about the only way to eat an elephant is one bite at a time comes to mind. However, while approaching a decision or problem methodically can often make sense, tackling some problems too slowly or without a plan can lead to significant unpleasant consequences. For instance, if you really try to eat an elephant one little bit a day by just leaving it the way it is and taking a bite a few times a day, by the time you get a few days in that meat is something substantially less than “fresh.” You’d need to work methodically and immediately to butcher and preserve the meat in some fashion in order to be able to actually eat the entire elephant.
A real-life example that I like to think of is when a doctor tells a patient that their health is in jeopardy if they don’t substantially alter their lifestyle with the ultimate goal to maintain a healthier weight and exercise routine. This doesn’t happen in a healthy way without immediate action and a realistic plan; going too slowly or not taking action will result in a patient not moving the needle at all to improve their health. If they move too slowly to take action, by the time they’ve made any substantial changes they’ve likely suffered negative health consequences because it’s been years since the change was suggested by their doctor in the first place. If you need to get your cholesterol down substantially, you can’t do it 1 cholesterol point per year.
In all of the above examples, there is discomfort encountered. Cutting your budget by $500 per month all year is not enjoyable. Neither is needing lose a fair amount of weight and incorporating more exercise into your routine (I know, I’ve done it before). Even eating an elephant is probably not that much fun – I tend to prefer watching them roam around.
Every time I see any rot or anything on my house, I logically assume this is where things end up in a week. I’m not usually wrong.
But on the other hand, NOT doing something in each of these situations also has its own discomfort. Cutting your budget by $1500 per month because you waited until September might be more painful than $500 per month all year. Needing medical intervention due to obesity or heart disease may very well be worse than adjusting to a healthier lifestyle. And eating rotten elephant meat… well.. never mind. Don’t even get me started on what happens if you put off home maintenance. I’ve seen way too many houses with substantial repair bills because they didn’t take care of small problems before they became big ones. Including, as I mentioned above… me.
In each of these examples, you are going to encounter discomfort, difficulty, or more simply put - pain. You’re going to experience pain in any of the above situations. The only thing you’re allowed to choose is how and when you experience that pain. You can take the pain of fixing the trim board, or you can take the pain of fixing the whole garage wall. You can take the pain of making healthier lifestyle choices, or you can take the pain of long-term medical issues. You can take the pain of cutting your budget by a manageable amount in January, or by a catastrophic amount in September. You make a decision of what to or not to do, and there are consequences.
I call this the pain curve. I originally thought of this when it came to giving financial advice while leading a budgeting course in our community. For a while, people came to me with questions about their finances and I’d try to give them some advice on what I would (or could) do if I was in their position. Ultimately, it usually came down to the simple advice of “take the pain now by setting up and maintaining a better budget, or take the pain later in the form of severe financial difficulties.”
But the end result was always the same: there’s pain you cannot avoid - you can just choose how to take it.
Now, let’s talk about technology. And because I’m cognizant of the fact that I’m already 12000 words into this post, this will be a two-part post. I just don’t want to end without talking about different ways that this manifests itself in a technology practice or management – because there are a ton of ways the pain curve plays out every day in IT. Tech Debt, security, infrastructure flexibility, and application modernization are all ways this plays out in IT shops around the world. Today, I just want to focus on one of those: technical debt. Actually, what I really want to focus on is security, but that’s too long for the space I have left, so we’re doing that in the next post.
I’m sure most are familiar with tech debt, but since I do occasionally have readers from outside of IT (I welcome everyone!) I thought I’d try to define it. In my own words, technical debt is the cost you will incur in the future for work that isn’t being done now. That could be because you opted for the easy, quick fix to something instead of the “right” way to fix something, or it could be the cost of deferred maintenance. Maybe you missed an upgrade, so now when you want to upgrade a piece of software you’re out of support and it’s much harder. The point is, it’s work or cost that you are going to have to do because of a decision you made today.
“I don’t know… rebuilding this seems hard and expensive. Can we just patch it?”
“….No.”
“Okay, we’ll go with your idea, then. Leave it unpatched. What’s next?”
In everything we do in IT, there is some implied pain that comes along with it. Upgrading every server you have to a currently supported OS takes time, and can be complicated if you’re running legacy software that has compatibility issues with later OSes. But so is refactoring your applications to be cloud native or migrating to new applications. These things are time consuming, costly, and… painful. But if you do nothing at all, ultimately your application will stop being useful, secure, or functional. And then you have a whole different kind of pain – such as an outage or loss of competitiveness. Imagine if American Airlines never updated their apps to be able to book a flight online. They’d be out of customers by now – I’m not calling anyone to book a flight, thank you very much.
The pain curve in IT operations can often look a lot like the home maintenance issue; take a moderate (though measurable) amount of pain now in order to get your applications in good working order, or take what is likely to be much more pain later by kicking the can down the road now. Do you want to fix one board, or the entire wall?
But what about migrations or upgrades? We’ve all been part of a project to move from one platform to another that has taken over a year because the attempt was to slow down the rate of change so that users have time to adjust. Likewise, I’m sure you’ve seen the other end of that spectrum – knife edge cutovers that happen at a set point in time where everyone gets migrated together. These are two extreme ends of the same continuum – trading time for intensity of discomfort. This is where the idea of a pain curve really shines. You can sometimes decide to take a small amount of pain spread over a longer time, or you can take more pain over a shorter period of time. It’s the area under that curve that determines the total amount of pain that you’re going to incur.
In our example up above of adjusting to a healthier lifestyle that took too long to be useful, migrations that take years can have the same effect. I once was part of an app rollout that took literal years, and by the time it was fully implemented it was already outdated and the interoperability issues (pain) towards the end of the project started to increase. So, in an attempt to minimize the amount of pain taken at any given time, the company signed up for a substantially higher total amount of pain.
True story: Someone just told this kid they’re going to be in IT when they grow up.
Hopefully you’re seeing where I’m going with this concept. You can’t avoid the pain – but you can choose when and where to take it and sometimes, your decisions will impact the total amount of pain incurred. That’s what I’m encouraging you to stay focused on: balancing the total amount of pain with when, where, and how you take it. We all live in a world with finite resources. You can’t tackle every problem head-on with a full-court press and a full team because you have limited time, people, and financial resources. Often, you’re trying to balance multiple separate curves in an attempt to harmonize one big pain curve.
The challenge is to make sure that you’re not just pushing all the pain to “later.” Later comes sooner than you’d think, and I hope you aren’t intentionally or unintentionally signing yourself up for a whole lot of pain when it gets here.
In part two, I’ll look at the pain curve as it relates to IT Security. Don’t worry – there’s plenty of pain to talk about in cyber security.
Questions for thought:
Have you ever put off project (home, work, personal) that ended up costing you more pain because you did?
Have you ever been part of a project that took on more total pain because they were trying to minimize the amount of pain taken at once? How did that work out?
What pain (tasks) can you take on now to minimize the pain coming in the next two years?
