From Zero to Grok in 5 Easy Steps
It’s no secret (and only slightly disingenous to say) that all systems become legacy systems the second they hit production. When code, if even for a second, has been part of a system that has successfully served production traffic, there is cognitive overhead (even if token) required in changing or removing it.
There comes a time for everyone when they are given a pile of code and told “go make that better.” That has happened to me my entire career.
When I first entered “the IT industry” back in high school, I worked at a police station (among other places). The previous IT staff left and I was given an AS/400 (with no terminals), and an old VMS service. This was in 2004 - these systems were ‘traditional’ legacy.
Just a couple of months ago, I moved into a new position at my current employer. I’ve been given a semi-homebrewed, self-service Continuous Delivery system used by several teams in the company. The system has been around for a year or so, but has only seen real use in the past couple of months. ‘Non-traditional’ legacy.
My responses to both of these situations - and all the ones in between - have been (roughly) the same. It doesn’t matter that one was a traditional Ops role and one is more DevOpsy.
This is a big part of being a decent human being in general. And it is, unsurprisingly, a big theme here.
Coming into a situation, it is very easy to judge the people that came before you. As you’re taking stock of things, it’s easy to ask yourself “what moron designed this?” It’s easy to get annoyed or even angry. It’s easy to dehumanize those people.
But keep an open mind. Do not fear the system. Fear is the path to the Dark Side. Wasting your engergy complaining about how things are and hating “those responsible” isn’t helping anything.
Have empathy for those who came before you. You don’t know what situations led to the creation of what you see before you today.
Just say yourself a serenity prayer and…
I’m not saying you can’t have opinions. And I’m not saying that you can’t have a burning desire to make things better. As a matter of fact, both of those things are required.
You should perform an inspection of the system. Just with a bit more empathy than Mike Holmes. Especially when you’re at a company where the people who built it are likely to still be around.
If you go into the inspection with an open mind, you’ll probably find that even the craziest and most convoluted systems can make a sick sort of sense. Poke through different, discrete parts of the system and you will likely see patterns emerge. Even if the architecture is “wrong” or there is a complete lack of “design patterns,” there will be some kind of logic you can latch onto and apply throughout and the system.
Don’t get too deep into the system, just get a feel for it. Make notes about how major components fit together. And about broad improvements that need to be made.
Interview your customers - the people that use the system. Have them walk you though a typical task that uses the system.
Listen to what they say. Watch what they do in order to hear what they don’t say. Ask them questions.
Write everything down.
Don’t respond to their comments, just make notes. Seriously, don’t respond to any requests or complaints. Especially don’t get defensive. This will shut down the interview and you won’t get any useful information.
Condense the notes from your inspection and your interviews. Find common themes. Group them logically - by components, modules, functions, whatever.
Make a map of the system as you understand it. A diagram, mind map, or just a flat list. Separate out major components or concepts. Attach your inspection and interview notes to the relevant places.
[TODO: Post an example image, because this really is key. And awesome.]
This will get you a holistic view of the system. You can get some insights into what parts aren’t functioning correctly and give you a to-do list. But, perhaps more importantly, it can give you some insights into how and why things currently work the way they do.
See why keeping an open mind was a good idea?
A huge piece of your list is probably of the “to do” variety. I want you to cross out half of the items before you even prioritize. There is plenty of stuff you don’t actually need to do. It might bug you that some things are “wrong.” But, if it works reasonably well and the customers are happy you can probably be delivering more value elsewhere.
Now take the rest of the “to do”-ish items and attach all of the relevant “note”-ish items to them. Now you can make a to-do list.
At this point, you should have a good idea of:
How the major components of the system work
* And maybe some idea as to why they work how they do
- Which components maybe don’t work so well3. The biggest problems experienced by your customers4. Which items you’re going to address first.
Now that you know what to do, and have a better idea of how to do it…go do it.