It’s just not enough to be right…

Have you ever been in a situation where you knew your team/company/organization was going down the wrong road, but you couldn’t stop it?  One of my best courses in college was engineering communication.  One of the things we studied in the class was a case study about the Three Mile Incident in the late 70′s.  The technical flaw in the nuclear plant cooling system that led to the accident had been identified by an engineer well in advance of the accident.  We studied the chain of memorandum’s that the engineer sent out about the problem, and the reasons why his communication approach was ineffective in bringing attention to the potential danger.  The engineer was right, but he never got heard and might have failed to be heard because he didn’t go through the correct communication channels.


I’ve had a few of those situations myself where you saw failure and problems coming but couldn’t or didn’t manage to prevent them.  A couple years back I was the responsible architect in a “Build vs. Buy” analysis.  The business wanted to replace a goofy web application with something more robust that could handle different business workflows.  As I recall the application was primarily written as a VB6 component that created elaborate html with a whole bunch of  html = html & “<td color=red>” & rs(“title”) & “</td>” action.  It was created in the euphoric aftermath of the original IE 4.0 DHTML model so a bunch of user actions spawned a request back to the server to get a chunk of html to stick in an “innerHtml” property.  Needless to say, it was slow and kloogey.


The envisioned replacement would be a very small, but usable user interface with maybe 4-5 screens total, but like the proverbial iceberg was going to require about a dozen integrations behind the scenes.  At the end of the analysis we came down to three possibilities:



  1. Just write it ourselves.  The application itself was trivial and it’s always easiest to integrate your own code.
  2. 3rd party system that used ActiveX controls on the client (non-starter).  We had another system from this vendor that was apparently a maintenance nightmare and I didn’t want anything to do with it.
  3. Vaporware system from a dodgy startup company.  We, inevitably, would be their very first customer.

I made a big enough stink about the ActiveX control deployment to prevent #2, but the business didn’t trust IT (and I don’t blame them), so they picked #3.  Over and over again we had warned the business that #3 didn’t actually exist and the company didn’t look viable in the long term.  I left the company shortly afterwards.  On my way out I told the business partner that I thought the startup would be 6 months late delivering the system.  The real number was 9 months late on what was supposed to be a six month project in total.  A year later my old company decided to change their fiscal calendar schedule.  When they asked the software vendor how to do the reconfiguration, they were told that it would require a code change.  They ended up taking the system down for a full month while the vendor changed the hard-coded fiscal calendar.


I bumped into a former colleague today who told me that the system was the only reason he had to carry a support pager.  Sigh.


 


P.S — I swear I’ll never go back to a big internal IT shop.  No way, no how.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jeremy D. Miller

    Shoddy -

    I think I’m gonna hit this in a longer post later. By big IT shop I’m thinking Fortune 100 internal shop with thousands of folks in the internal IT department. I know that a lot of people do just fine in this environment, but it wasn’t a Jeremy-friendly place. I’ve worked for and in four different Fortune 100 IT shops and all four had endemic, structural problems in their IT operations.

    By small Agile (big “A”) shop I’m thinking in the hundreds (we’re at a 100 people overall, somewhere around 25 developers total).

    All it really comes down to me is what I get to do. In a really big shop you’re much more concerned with process, politics, and threading the bureacracy. In a smaller shop, or at least in an Agile shop, you seem to worry more about building software.

  • http://www.shoddycoder.net Shoddy

    I’m curious for point of reference, what is your definition of small agile shop vs big IT shop? # of employees wise…

  • Carlton

    I find what you say about age being very true. Unless you have got a few gray hairs and creases around the eyes, you aren’t taken too seriously. I know that has been my experience in the past and continues to be the case now. Oh well, someday these old fossils with their waterfall\RUP ideas and months of “detailed” design will retire.

  • Jeremy D. Miller

    Carlton, Dennis — I’m sorry, but I really don’t know. All I really learned is where I do and do not want to work. Success at on the big internal shops is dependent more upon your organizational or political skill than your technical skill or knowledge. You have to know who the right person is to talk to about these kind of problems, and hopefully have some level of respect from management. At the time of the incident I described in the post, I had no real relationship with senior management and probably wasn’t taken very seriously anyway because of my age. The fact that the IT organization was severely mistrusted by the business unit made things very difficult.

    It isn’t a real answer, but all I learned is that it’s much better for me to be in a small Agile shop where the communication is more frequent and bidirectional between our management and the technical team.

    All I learned in college and since is that a good technical communication makes its point in clear language in the first couple of sentences in language appropriate for the audience.. For manager types, you have to explain things in their language. You just have to clearly spell out the risks and try to quantify costs.

  • http://www.bloggingabout.net/blogs/dennis/ Dennis van der Stelt

    What _IS_ the right way to communicate these things then?!

  • Carlton

    I am curious to know what you have learned since then that has prevented the same situation from coming up again? Or what you think you missed from the last time?