How innovation can turn to burning hell

During years in software development business I have seen many cases when layering in system architecture is made innovative way and later innovation turns out to be the worst nightmare developers and their managers have ever seen. Years ago I got very painful experience on how things can fail with unapproved bleeding-edge technologies that were selected to support sales to customer. Let’s take a look at hell for a moment.

Introduction

The company I worked went for project of some possibly very good customer. Opportunities to make some good money seemed very high and to beat competitors the company decided to offer solution that makes also use of new advanced technologies.

I was young techie and I used a lot of my spare time to play with all those new things, trying to make them work and trying to find out how to use those technologies. I had better understanding of all this new web stuff than elder guys in companies but there was no way for young techies in this company to stop veterans and one extremely stupid manager to shoot bullets to heads.

I saw disaster coming but as we had one way too enthusiastic maniac in project who was older than me and had more experiences with unstable managers then he was on good position to stuff the offer with most dangerous ideas. Seeing that I am in project with one maniac who has no idea what he is doing and with manager who knows about technology less than cannibals on abandoned island I just gave up – let’s see what happens.

“Innovation”

Innovation seemed weird to me because it was all about how to use new features of Internet Explorer and build web application framework to support those fancy things. This time Netscape was another mayor player in browser market but they were not prepared to powerful applications. By example – modal dialogs were supported out-of-box by IE but on Netscape you had to use very unstable JabaScript hacks that made Netscape crash easily and so on. As it was application for internal use it was safe to demand IE from users.

All fancy things in IE like support for XML, XSL and XSLT were unstable, inconvenient to use and totally unnecessary in project context where we needed just browser-based application. Why not write simple and classic forms and add some client-side functionalities on JavaScript level and avoid all this ActiveX stuff that XML introduces? No, it’s not a way to go – it’s not innovative and outstanding.

As on the other side of table was “reputable” manager who has moved from one respected company to another during last year three or four times for unkown reasons I stopped my questions and pitching ideas because step by step the discussion showed me that on the other side of table there is black hole.

How innovation turned to disaster

During first month everything seemed okay. There was pointless amount of coding for even simplest form you can imagine, framework then older “professional” was writing and against what he felt almost perverse love still evolved and some things actually went better. But many things got worse – weird data access layer that was built by combining first ideas grew to big beast. The code was organized to some point but I was not happy with it because it left too much work for me – UI side + data exchange developer.

The problems that grew extremely painful are here:

• DAL – long and loosely organized classes that left too much visible of their internals and that had no nice and clean public interface (debugging these classes was also difficult),
• Data exchange – XSL-based forms that were generated on server and rendered in browser included also all JavaScript necessary to provide client-side functionalities were hard to debug because some parts of JavaScript were generated in server,
• XML/XSL/XSLT – as it was mostly the job of some unstable ActiveX components offered with IE there were a lot of unexpected crashes and it was extremely difficult to find out reasons of crashes as I was not able to debug General Protection Faults and other hardcore errors like this,
• Often changing requirements – as project manager spent a lot of time drawing completely useless UML-diagrams (these diagrams were useless both to developers and customers) he wasn’t able to work hard on requirements and logic of most complex parts of system – can you imagine how painful it is to change some complex processes when you have time around 10 hours?
• Weird issues with IE – if everything works in our office on developer and testing machines it doesn’t mean there is no evil hidden in customers machines. Some machines faced weird issues with those ActiveX components and introduced new crashes while other machines worked well,

It took some months of sleepless hours to get this fancy and “innovative” beast work stable and do what customers need. I still don’t believe that this system is something they were using for years because new client-side technologies and multi-browser platforms also introduced way better UI technologies. Who knows how this system lives, maybe it’s still there but I hope to never hear about it again.

Conclusion

Innovation in software projects doesn’t meen piling up load of bleeding-edge technologies and selling the experiment as silver bullet to customer problems. When you are young you often must do what you are told to do and all your considered resistance is something that is problematic topic behind the closed doors when your fate in company can be decided by incompetent people who are on higher position. If you are put to death march project that is death march not because of unexpected issues but because of stupid decisions and poorly managed processes then run – run for your life. Later, believe me, you have nothing to regret.