Mythical Man Month, Project Failures and the Knight in Shining Armor

Mythical Man Month is the title of a collection of essays in software engineering  and project management - covering the  good and bad practices in the IT sector. It was first written in the 70s and later updated in the 80s and 90s subsequently.

One of the chapters in the book that caught my fancy then was the one aptly titled - "The second time effect". Basically, the chapter is a treatise about the desire to tend to over do things when given the chance to upgrade or rewrite an existing application - so called version 2.0

There is always the tendency attempting to fix all the so called real and imaginary flaws found in version 1 and more often than not - you'll end up with a revised edition that is unduly bulky and overtly prone to more errors than version 1.

I had a first hand experience in a similar situation and I'll be sharing my observations and hopefully, this could serve as a panacea to avoid a similar pitfall.

Essentially, I became the honcho man supervising the incremental feature development and production maintenance for a pair of applications that were intertwined but used in serving more or less  the same user base. 

One application was regarded as the upstream application used in determining eligibility for a defined  set of services and the other, regarded as the downstream application was used in setting up the services for the user base that has been deemed eligible for same.

Unfortunately - the two applications were implemented at different times - the upstream being the first developed and deployed before the downstream was and thus - they had different topologies or platforms. The upstream was a Silverlight based application while the downstream was a pure web based application.

The choice of Silverlight as the framework for developing the upstream application was majorly based on the ability to run the application in online and offline modes. Online mode refers to a situation where the application is connected to a central repository or database in real time and offline mode refers to the ability of the application to still being able to run even when not connected to the central repository.

A quick background - the upstream application was conceived about years ago when internet connectivity was not yet universally available and there were still challenges in some remote areas of getting connected to the internet. So, the thought process then was - if there was internet connectivity - use the online mode, if there was no internet connectivity available - use the offline mode.

On paper, it was a noble idea - probably the next best thing conceived since the notion of sliced bread came about. As usual with grandiose ideas, the Devil is always in the details. The workflow was - when going offline mode - check out all the required artifacts needed to allow work in offline mode and when transitioning back online, upload all the changes done in offline mode, reconcile with current state of the central repository and make the delta changes permanent in the central repository.

Again, the concept was beautiful and stake holders bought onto it but over time, data corruption and loss started occurring at the point of reconciliation leading to users having to re-enter/remember all the activities done in offline mode thereby leading to high number of  frustration fits and lack of confidence in the application by the end users.

Alongside the user experience issues, was the end of life or support issue. The integral selling point for the Silverlight framework was the ability to run in online or offline mode but with the advent of the HTML5, this became a non issue as isolated storage became part of the standard feature set.

That alternative to data persistence in  offline mode and the fact that  the Silverlight framework was mostly compatible with Internet Explorer - albeit, a couple of other browsers tried to support the framework via plug-ins but Silverlight was better run in Internet Explorer than any other browser.

Long story short, Mircosoft decided to pull the plug on Silverlight and set an end of life date of 4th quarter of 2020. So, there was increased pressure from all the major stake holders to upgrade the application with two primary goals in site :-

1. Replace the underlying framework - Silverlight - facing the upcoming end of life.

2. Improve the application stability as well as end users experience.

Due to newer HTML5 standard, offline storage is now an integral part of the standard and pure web based application can also support online/offline data persistence as well as the fact that - to an extent - Silverlight is proprietary and confined to mainly IE browsers ( some other browsers supported it via plugins )

Anyway, long story short or short story long - take your pick, a new project initiative was kick started to get a replacement for the Silverlight based application. Unfortunately, we had too many cooks in the kitchen, UI, QA, BA, Stake Holders, Dev Ops, Support and Development teams. At the end of the initiative, a draft document with varying requirements not really focused on the core buisness needs but rather mundane things like color scheme, font size was spun off.

As the Software Development manager, my proposal was to do a piecemeal conversion and not wholesale - meaning - do not do an entire re-write from grounds up but rather do what I referred to as "re-skining". Leave the existing underlying workflow as it was but rather do a direct port of the functionality from a Silverlight based ecosystem to that of SPA - Singe Page Application Architecture using the Angular >= 2.0 framework. Basicslly - a thin client with lots of AJAX calls to a Rest Service API with an optional flexibility for multi-tier seperation of the business rules validation rules from the data persistence end points.The anticipation was that - it would allow for both vertical and horizontal scaling as well as load balancing without re-inventing the wheel.

Unfortunatley, my pitch was not bought as everybody else wanted a full blown modern project approach with unreliastic mile stones and practically impossible deliverables. We tried everything we could with the so called modern project approach but we were fell short of meeting up with the milestones mainly due to insistence by other stake holders to conformity with undue modern project approach - which mainly added to the list of deliverable of features not really related to the core functionality of the application.

At the end the day- the effort was a failure, the intiiative was scrubbed and my originally idea of doing a "re-skining" was implemented by converting the Silverlight app to a WPF app.

The lesson here is that - doing a re-write of an existing application is not always easy as it might look on paper. Secondly, when doing a re-write, try and limit or prune down the number of people with veto on the project. Limit it to the core Busines Owners as well as Subject Matter Experts that can provide positive guidance for the re-write initiative.

Lastly, when doing a re-write - especially to do with platform change or underlying technology, try not to introduce new features - stick with the existing tested features. Once your re-write is successful, you can then start mulling over about adding new features and all that.