Change is hard, but possible, or, It’s the still the case that you should stop hitting yourself
Improving is never easy, and that’s certainly true when it comes to how large organizations improve how they do software. While it can seem like a curse, I’m lucky to talk with people at organizations who are struggling to improve. By the nature of the work Pivotal does, we spend a lot of time talking with organizations who want to be more agile, shift to a DevOps approach, and other wise (to a buzz-phrase) become “cloud native.”
As I’m fond of putting it, they just want to get better at software. The first step is to stop hitting yourself, as we’ve discussed before. But that’s just a eye-rolling bon mot, really. You actually have to do some work.
The road to better software is paved with white collar pain. It’s like (as I’m told) when you start working out: it hurts, for, like, several years, and then you sort of start to enjoy it and maybe can live 0.7 years longer.
Let’s look at a couple of those common pains.
The Pain of legacy process (aka “culture”)
Perhaps the most frequent question is something like:
“How do we reconcile [old processes we don’t like] with DevOps [or whatever new way of doing things we now want to do?”
Well, that’s the 23% CAGR over 5 years question right there. I’d start with understanding what DevOps (or whatever process you want to switch to) is, and why it is (DevOps wants to ensure that you can deploy software weekly so you can always be improving it, and that it actually works [has uptime and resilience]).
At that point, you ask “does our current process do that”? If not, then you have to get executives to change how the organization runs. There’s no short cuts or easy cuts, you just have to do it over the course of *years*.
In contrast, to “virtualize,” you sort of just install VMware and after a few years you have huge ROI and savings. (Granted, the truth of virtualization is that it ruffled all sorts of feathers in IT departments in the 2000s and people were all up in arms and chickens without heads running around and cats and dogs living together …we just forget all that ;>)
Put another way “you’re going to change and eliminate those processes. GET READY FOR A SURPRISE!”
One of the chief characteristics of large organizations is that you have to convince the organization to actually do anything. We have these visions that executives in large organizations can actually make the trains run on time, as it were. Nope.
Thus, when it comes to change, you have to spend much of your time doing internal marketing to sell it up the chain, to your peers, and to your own organization.
To my mind, the only ways to do internal marketing well is to either (1.) already be successful, or, (2.) get executives at other companies to tell you and your organization How They Did It And That It Worked.
The first is just a recursive noop (“success breeds success” and other such nonsense). Thankfully, when it comes to the second, there’s a lot help now-a-days, primary in the form of there change agents who’ve gone through this themselves.
How did these executives succeed? By actually trying: picking small projects at first, learning the new way, succeeding (and hiding failures), then trying bigger things, and then telling people about it by making money. After all, success breeds success, right?
They also fire, er, “re-allocate” a lot of people, which they don’t talk about a lot in big glitzy keynotes but do over drinks in loud bars.
Of course, vendors (like myself) saying all this is pretty useless. We’re not trustworthy, after all, and are better at unicorn management and breeding programs than tending to the donkey ranches.
So, let me direct you to some “actual” people who’ve gone through all this:
- Tony McCulley from Home Depot has two good talks walking antiseptically through two years of Home Depot changing how they do software. Check out the first from 2015, then the update from this year. (He’ll be speaking at Gartner’s appdev conference this December if you’re looking for some pre-Holidays jollies.).
- Matt Curry on changing bureaucracy and internal marketing: this is the beloved “stick the SVP in a t-shirt and ‘oh, it’s OK if you kill yourself outside the building’” talk.
- Brian Gregory on starting change at Express Scripts, and also in a recent webinar we did together.
There’s many more “talks” that aren’t recorded, you just have to find the right people and sit down with them to chat.
How do we migrate legacy software?
There are no good answers here. This is like someone with terminal lung cancer asking for help on stopping smoking. I suppose that’s gas-lighting…but if “legacy” is what’s holding you back it means you’re not managing technical debt well. Stick all your enterprise architects in a room (maybe even have an open bar!) and gently ask them, “so…what would you say you do around here?”
Updating legacy software is hard. The problem with “lift and shift” (which many vendors like to wrap fancy slides around) is that the “cloud native” benefits you’re looking to get are not only from the platform you run your software on, but from how the software itself is written (and, then, obviously, then, how you manage and operate it in production).
Sure, you could just dump some three tier, MVC, hairball into a WAR file and spoot it out into some container orchestrated cloud thing…but all you’ll new have is a big lever that says “reboot” on it. With brute-migration there won’t be:
- All the resiliency advantages of little blue/green man deploys, canary parties, feature flag burnings, bulk-bin heads, etc.,
- The ability to to start deploying weekly or even daily to improve how software is done (i.e., “you don’t operate in an agile way”)
- And, you know, you still have to make sure it all runs in production properly tomorrow.
Worse: the original problem still isn’t fixed. The next time you need to pay down your technical debt so you can improve/do things in a better way, you’ll still have the same old crap weighing you down, just with a different compression format and file extension.
I think there’s plenty of “hacks” to be had to extend legacy software’s value; that is, not having to spend time and money on updating/refactor/rewriting them). I hear Oracle has some bridge-themed tools if you like your current parking arrangements, and there’s always queues, amirght? You could probably do a lot worse than doing some BCG matrix trust-falls to find your low-priority, little used apps and shipping them off to an MSP, AWS, or one of those data centers that’s sitting there purring like an old cat with crusty eyes and renal issues.
The point of Whatever The New Approach You Want To Do is: when you want to write software in the best way possible, do it the new way, not the way you’ve been doing.
There’s some more instructive help from people like my pals Kenny and Rohit, to be sure. You can find plenty of content like this that speaks to how to start picking away at the scabs of legacy. As with peeling off any scab, it’s important to know that the skin underneath it is healed, or you just re-bleed. That’s probably how you should treat migrating legacy applications.
Like I said: no good answers here, just lots of work and risk of bleeding.
That sounds great, but where the hell do I start?
Getting started is vexing. Essentially, you need to pick low-risk projects that are still “material” to the business. I just happen to have a draft of some advice here “from the streets” in this little excerpt from a new booklet I’m working on.
Good luck, be sure to tell us how it goes
If you’re struggling with stopping hitting yourself, the best next step is to find other people who’re struggling and to talk with them. You then need to “see it to believe it” and, then, really, just start trying. There’s no universal bromide or DVD you can install. There is, however, a way of thinking — a process even — you can apply, namely: learning and slowly changing towards the better.
(And, you know, there’s lots of people hiring if you find yourself a rat on a sinking ship.)