CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

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.



Comments

Dennis van der Stelt said:

What _IS_ the right way to communicate these things then?!
# November 11, 2005 2:58 AM

Jeremy D. Miller said:

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.
# November 11, 2005 8:12 AM

Carlton said:

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.
# November 11, 2005 11:45 AM

Shoddy said:

I'm curious for point of reference, what is your definition of small agile shop vs big IT shop? # of employees wise...
# November 13, 2005 5:14 PM

Jeremy D. Miller said:

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.
# November 13, 2005 9:54 PM

Jeremy D. Miller -- The Shade Tree Developer said:

Between being extremely short handed at work, tech' reviewing a new book, a
possible book proposal...
# August 7, 2006 4:51 PM

Jeremy D. Miller -- The Shade Tree Developer said:

Between being extremely short handed at work, tech&#39; reviewing a new book, a possible book proposal

# September 1, 2006 2:33 PM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Jeremy D. Miller

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 previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#. Check out Devlicio.us!

This Blog

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab

TestDriven

MVP