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.


3 thoughts on “How innovation can turn to burning hell

  • Hajan says:

    Interesting enough, but this story seems like Deja Vu for me. It’s definitely true that bleeding-edge technologies bring with itself the risk of instability and carrying bugs inside them which may complicate developer’s life exponentially. Therefor, those in higher position must be very careful when making decisions, should try to be more pro-active about these decisions and try to gather as much feedback as possible from the team.

  • bob says:

    i think that users have to be made aware of the fact that most projects come in very late and that they have to comprimise between clunkyness and slickness for maintainablity purposes. For example, in my younger programming days i would relish the challenges of the new technologies and try to come up with 1 click solutions, but they are often more complex high maintenance solutions and when i saw the “clunky” Sharepoint solutions, i first didn’t like the approach, but now when i think of how developers are getting burned out and discarded and i see the intelligence in the Infopath form attempts, i now realize that everyone will have to “comprimise” between slickness and clunkyness to keep the development environment a civilized place for all, ie we can’t keep burning people out and creating maintenance nightmares and sure many complain about Infopath “clunkyness” but i think its the best attempt every at incorporating a “rule based” approach that we all dream and tout about and i now see that its getting better and better every year, ie Nintex, and that tells me the future is the 80/20 rule, use the computer to fight fire with fire and use a META approach wherever you can, and yes its been a pipe dream for years, but i can now see its becoming a reality, but the users will have to continue accepting a bit of “clunkyness” and maybe 2 clicks insstead of 1 click

  • Gunnar says:

    I’m not against new technologies at all but same time I think that before using something new this something new must be well evaluated. Plus – never break the KISS principle, it comes back to you as nightmare 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *