Where are the IT Ops 'Gang of Four'?

The A-Team were infamous for their problem solving. Most problems involved guns, baddies that were exceptionally bad at using guns and cars that flip over when the wind blows. However this is not the gang that inspired this post...

The ones I'm referring to came to fame around 20 years ago. Some experienced software developers realised that a there were a lot of architectural problems that were common to the software design. If you were building a web based ticket system, you would face issue like how to map objects (tickets, users, groups) to tables in an SQL database. Or how separate the user interface code from the application logic so that UI changes didn't require changes to the application logic and vice versa. They called these challenges 'patterns' and four people wrote a book called "Software Design Patterns - Elements of Reusable Object Oriented Software". The authors names were Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, and in software circles they are known as the 'Gang of Four' (GoF). The book was a massive success in defining strategies to solve common problems and spawned a wave of books and software frameworks to explain and implement the patterns. 

As a result developers could be more productive because they spent less time re-inventing solutions. It became easier to built better quality applications because they already had proven building blocks to get started. 

So I thought that perhaps this is what's missing in the IT Operations scene, a definition of common problems and the best practices in solving them. In my experience, the best practices employed to deploy software services or servers varies from person to person. I still get mad when when I find Linux servers deployed with a single root partition for all the data - AARRGGHH!! I think there's a danger that we'll always be seen as hackers until we can bottle the expertise, distribute it, and build upon it.

But that just what I think. What are your thoughts?

Why I write

I've had few days off work and it's given me some mind space to think about why I started writing this blog and what I really wanted to write about. I'd say I was good at my job, but I'm not the most technical engineer. I know people with a greater depth of knowledge on networking, or storage or virtualization, but I've come to realise that it was never my goal to know as much as possible about Netapp or Puppet. I'm much more motivated by the problems you can solve with computing technologies and not the details of the technology itself. 

I started university on a Mechanical Engineering degree. Now as a kid I had used computers ever since I could get my hands on the school BBC Micro. But computer guys were geeks. I'd had seen the films and anybody who liked computers was geek and had no friends. I wanted friends... So, I also had a talent for design, and an interest in science so Mechanical Engineering was a logical choice. And the university brochures always showed engines of fast cars and jet engines. So obviously this is what I'd be designing when I'd finished... I was relatively happy in my choice but a friend was doing Electronic Engineering and something about it just seemed more attractive to me. And I was always one with ideas of things I wanted to build, but I quickly realised that in Mechanical Engineering you can't actually build a jet engine or a sports car, by yourself, in a bedroom. You would more likely be designing a piston or a drive shaft, and the 'big thing' would need big team with big resources. But with electronics, you can have an idea and implement the whole thing with much less resources. 

The idea to switch degree came when I was reading 'The Gap into Vision: Forbidden Knowledge' (the second book in the best series I've read to date). A group of space pirates were on a ship and there was a computer engineer who had fallen out with the Captain. He told the Captain he had planted a virus in the ships system so that if he was killed, the virus would spread and they would be unable to navigate their ship. The Captain was enraged but thought he was bluffing, so he killed the engineer anyway. It turns out that the engineer wasn't bluffing and the virus did unleash itself and even after they isolated the various components and cleaned them, the virus kept coming back. Then they discovered that the virus was actually in the hardware itself. 

OMG, how very ingenious! This was cool stuff - well not the killing part - but method he'd used to plant the virus. It occurred to me the with electronics and software, I could do so much. My powers would be limitless! 

I switched to Electronic Engineering. By the time I finished I had developed a taste for Linux and a little while later I was considering problems that could only be solved by developing software. Damn. I was back to being a geek. It seems you can't escape your calling. 

Should I have been a software developer? Well, no. In my view, software developers aren't as exposed to the day to day challenges of providing IT services to a business function. In IT Operations I'm regularly solving problems that impact the business and customers on a shorter time frame. This provides an opportunity to understand how to build IT services to serve people better. However it often seems that there's too much focus on the technology of the solution and not enough understanding of the problem. 

So I write because I'm an engineer who believes that the real problems are solved by better engineering and not just better technology. 

You might be my manager, but know your place...

I love what I do. But I have to admit, I've spent a lot of time developing personal coping mechanisms to deal with various frustrations that seems to be routine in IT. Today I going to talk about the issue of 'function'.

Everybody in IT has their function. Developers develop. Testers test. Operations engineers make sure everything operates correctly. Managers manage. I like this kind of system, it's simple and makes sure that everybody knows what they're responsible for.

But what I hate is when people try to take responsibility for things outside their function. Too often this comes from management. If you're my manager, I'm happy to be managed. But when it comes to the engineering solutions, let me deal with that. Because it's my job. I understand that sometimes there are business requirements that can conflict with a solution, such as price, time to deliver, company strategy, internal politics, whatever... But when it comes to deciding how a solution will be implemented, that my domain. You want backups? You got it. You say I have to use Netbackup/Tivoli/some-specific-product to achieve it, you need to justify why it's the best for this problem. Otherwise, stick to management.

At the core, I believe that many of my own frustrations and those of people I've worked with, comes down to respecting the functions of the people in the company and knowing where to draw the line of responsibility. By this I mean if a developer tells me she has requirement x for the software she needs to deploy, the I should accommodate her requirements unless I can justify a different course of action that would better serve the business objective. And if I say to my manager "To solve this problem I need x,y and z," my manager should do the same.

If everybody does their job the way it was supposed to be done, work will be a much happier place.