Simplicity

Over my career in IT, I've been continually amazed at how many of my IT brethren and (uhh.. sistren?) get bogged down in making things more complicated than need be.    I tend to expect that one day, I'll be in the position to see the need to overcomplicate things and that I'll look back and realize that "they were right all along."

 or... maybe they aren't.  Maybe the KISS principle is a sound philosophy.

I've worked with many bright (much smarter than me) developers who, when tasked to add a feature, decide to "rewrite it" because ...it.... wasn't in their coding style.   I've met many (most) system engineers that build out systems in complicated and convoluted manners in order to scale to future needs.

The future needs are important to take into factor, I agree.

But, how much is too much complexity?

Our social systems tend to have a gravity towards complexity.   Small groups turn into departments which in turn give birth to committees.   Before you know it, project champions and subcommittees are making decisions that are so far left or right of common sense that they border on the stupid.   

Then, there's the sin of complexity through protectionism.

A "network guy" that I've worked with repetitively sins in this direction.   He and his group wield all of the keys to access to all sides of the network (as they should).

The problem is that they are not benevolent gatekeepers.   Instead, he and his bunch are suspicious and paranoid, untrusting and uncommunicative.

"Hey look, the CTO says we need to make this thing happen ASAP.  Can we  work together on this, can you get me the systems resources I need?"

"Nope."

Where I come from, when your boss tells you to do something.  You do it.    If that something can cause harm, you add a carefully worded warning but you still do it.

One of these system guys once told me this story, the justification behind their madness.

A nefarious and evil software engineer (like me) built and packaged an update to a 911 calling system for them to deploy.   (Because.. ya know… developers cannot deploy their own code..   the result of that.. would be.. like the Keymaster and Gatekeeper making whoopy ala Ghostbusters' end times prophecies…) 

The code, when deployed to the production system, failed during the late night upgrade.   When the poor, pitiful sysadmin tried to contact that developer, their manager, nay : anyone, they were not able to.  The result was the Escambia County 911 computer system being down needlessly for hours until the necessary parties got to work the next day.

I was standing over his shoulder, asking to get my hands, temporarily, on the public-facing web server for the backend of an iPhone app that was not-yet-live and THIS was the reason I was not able to have such access.   Because someone else, year's ago, stranded him amidst a project and that person's job function matched mine.  The result?  To create a virtual machine copy of the production system, to move it to another V-Lan and to email me hours later when I could get into this sandbox to test the environment differences that caused the application to work incorrectly.

Fast forward a year and six months later.    A CTO came to me and asked, "hey, set up this software for us to try."   We needed a Virtual Machine to test with.   The request goes to IT and the response? -- "We don't have time."

It's funny..  they could make time to spin up Virtual Machine's in order to fulfill a protectionist agenda but when the Virtual Machine was needed for a project they didn't agree was important, suddenly delivering a Virtual Machine was an arduous task.

When I interviewed developers, I'd often look for those developers who have grown past the adolescent need to needless over-architect solutions for infinite scalability, to those who simply try to make the most pragmatic use of their time and can reasonably accept that the requirements of their project will change over time.

When I interviewed system administrators, I'd look for those individuals willing to work with software engineers towards a common goal.  Someone who could research and implement the necessary systems to drive the organizations' goals and still protect uptime and implement safe security practices.

Odds are, the companies you deal with on a day-to-day basis have IT Departments that do not work together with this degree of harmony.   This is the reason when you call a business, an automated system asks you for some information and the representative asks for the same information 5 minutes later.   Someone, in that company -- isn't working together and most likely aren't keeping it simple…