06 February 2010

When less is more

My IT career began in the early 1990's writing code for dbase 3 or 4, can't remember which.  Over the years I've had the opportunity to work my craft in the military, several media companies, and several financial related firms.  I've spend most of my career administering Unix servers in the server room.  I have seen a lot of wonderfully engineered solutions, and unfortunately, far too many poorly engineered solutions.

When I first get acquainted with a new environment, the basic tell-tale signs for me that a solution is poorly designed are solutions that are overly customized, overly complicated, and overly engineered.  In a nutshell, they fail to follow the KISS principle.  Most folks would agree with keeping the KISS principle, many would claim to be following it, few actually do.

On a couple of occasions I have worked in such environments.  Out of control crontabs, scripts with bizarre/unknown side-effects, strange daemons bound to ports that create cross-host dependencies that no one knew anything about were some of the all too common situations.  A former colleague actually suggested replacing the scheduler we were using with some strange lp print system hack (I'm not kidding about this).  Just because you can turn a screw does not mean you should, and simplicity doesn't necessarily negate elegance. By that I mean that the complexity of a system should not scale proportional to the size of an environment.  For example, if you have a system with 10 users, it would not be appropriate to install LDAP on the server just to store the 10 user accounts.  Conversely, if you have 500 systems with 5000 users, it would not be appropriate to store user accounts in /etc files just because it is the simplest solution.

While prevailing wisdom seems to dictate that complexity coupled with well hidden knowledge provides job security, I can personally attest to the fact that the opposite is true.  Companies such as EDS and IBM Global Services have made fortunes in shops that once thought that way.  Create an unmaintainable mess, suffer a severe outage or security breach, and you will be out of business or parent company/management will quickly tire of your lack of discipline and call in the big boys.  They will document, re-factor the whole environment, then throw junior admins at it armed with checklists. You will be looking for a job.

In my experience, the best way to ensure your survival is to find out why a company would hire one of these firms in the first place, and do all of the same work yourself.  Then you can go the extra mile adding value that will benefit your organization and the powers that be will be less likely to outsource you.  The idea is for you to give management no reason to get rid of you and provide many reasons to keep you.

Over the next several months I will be sharing my experience and observations on what works and what doesn't work. I invite all who read to participate by posting comments and questions. I am also here to learn from others.

I look forward to the discussion!
-Jon

No comments:

Post a Comment