Formalizing an Infrastructure

When I started the new job, I knew I would have a lot to learn. I have learned a lot, and I still have a lot more yet to learn. One of the things I have learned is that there is very little in the way of formalized process-oriented infrastructure here. System builds are done effectively the way they were done at my last job (which I wanted to fix but wasn’t ever given time or permission to fix) – which is to say, by hand with an instruction sheet nearby.

Lots of things are hand-copied around, or schlepped around using a script that does the equivalent of an scp then an “ssh root@<server> mv”. Formalized? Heh. Process-oriented? Right. Auditable? I can hear the paramedics yelling for defibrillators now, and the auditors haven’t even gotten here yet.

One of the things I wasn’t sure of was how many waves the company wanted me to make. Should I sit down, keep my mouth shut, and do it their way? Should I offer small changes to establish myself, then sit down and shut up? Or should I go all-in and make as many waves as necessary to fix things up and get them running right? In other words, am I supposed to be a quietly competent consultant, or a bombastically loud deity of a consultant?

Well, neither – they’re both too extreme. But much to my surprise, the company wants me to make waves. Lots of them. They want me to discuss things first, but if I see something broken, they want to know of my desire to rip it apart and fix it, and so far they have let me rip away. There’s one bit I’d love to rip out completely and redo from scratch, but it’s far too ingrained in too many areas for that to be an easy extraction, so I’m letting it stay in and just going to open a longer-term discussion about it.

But oh what glorious fun it is to tear apart and rebuild an entire infrastructure… especially when I’m so good at it, and it’s ultimately so easy! Yes, I said easy – it’s complex, but the complexity is due to size of the task, not difficulty. Hot diggity, I’m back at work!

Comments are closed.