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:
- Just write it ourselves. The application itself was trivial and it’s always easiest to integrate your own code.
- 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.
- 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.