The Effective CIO

Professionalism May 12, 2008

I am an engineer.  Specifically, a Software Engineer.  Although my career has taken me to a senior management position in my field, my core skills are those of the engineer. I am trained to evaluate, analyze, design, and solve problems. In the same way that every CFO is an Accountant, even as a CIO I am a Software Engineer.

To further cement that discipline, I am an Engineer from Georgia Tech, one of the finest engineering institutions on earth.  I carry the traditions and reputation of that school with me and am required to be not just an Engineer, but a Hell Of An Engineer.  To be anything less is a personal embarrassment and diminishes all those engineers that came before me and that will follow in my footsteps.

In short, I take this stuff pretty seriously.

This past week I had the unfortunate opportunity to deal with software that is the result of decidedly unprofessional engineers.  Various systems that we are in the process of deploying failed in test and early release because the developers were not professional, were not disciplined, did not care, and most certainly do not carry the title of Engineer.  I should note that this software is being supplied by external vendors; it is not the result of my team or anyone I work with.  Good thing, too.

In the first case, a team of developers decided to skip their normal quality control process and not fully test the customizations they are developing for us.  In the course of development, they also decided to replace, in mid-stream ,certain database drivers on the production system.  The result is that we were handed a system that in its first test spewed out 10,000 errors.  Fortunately, the system is limited to reporting 10,000 errors so it stopped at that point.

The lack of disciplined engineering allowed this team to break all sorts of rules.  The idea that you would develop and release code without testing is incomprehensible to me.  The idea that you would change a core system component on the fly, in production, is horrific.  That you would ultimately expose your customer to all this is embarrassing and unacceptable.

The second case involves a piece of software that has one of the worst configuration interfaces I’ve seen in a long time.  Without going into detail, be assured that it is confusing, cryptic, hard to use, and breaks dozens of well-understood UI design principles.  The fact that making a mistake in this interface would knock hundreds of users offline and potentially corrupt their personal data only makes it that much worse.  Whoever developed this interface truly did not care for the end user or make any effort to understand how the tool would be used.

How do these situations arise?  When we fail to train new members of our profession, discipline falters.  When we refuse to hold people to high standards, quality suffers.  When there is a lack of accountability, errors are tolerated.

As Professional Software Engineers, we are required to enforce the discipline our field requires to ensure that we have the trust and confidence of our users.  If we were building bridges or skyscrapers, we’d be in jail for these kinds of errors.  Although our failures may be less dramatic, they are no less important.

If you, like me, seek to carry the title of Software Engineer, take it seriously.  Wear it with pride, but earn the right to wear it, no matter what your position or title.