Mending Apps From Within vs Destroy&Rebuild

(Disclaimer: I explain technical things in non-technical fashions for a living; that being said the second half of this one gets a little hairy since its a case study and I need to explain the proof. Apologies in advance)

In software development, over 90% of projects are either past deadline or over budget at some point before project completion or ‘death’ (old Deloitte study; but I doubt it’s changed much). A large portion of these go through or get to a fixed state of disrepair; with a decision to make after the latest failed attempt to complete the project. Let’s call this state “lagging/stalled”.

The default decision for said ‘stalled’ project is, by a LARGE margin, to simply destroy and rebuild the project. And this decision is usually proposed and egged on by developers as most developers in the industry consistently sport a “build” mentality over a “mend” mentality. It’s the reason that companies like Corgibytes (Shoutouts to them and to Andrea Goulet in particular) are so unique just by virtue of wanting to go into client’s systems and fix systems from the inside rather than rebuilding from scratch.

There are times when Destroy&Rebuild is the perfect solution to a lagging/stalled software project. However, seeing as the split is 99/1 (very slight exaggeration :D) in favor of this mentality, we should probably consider when Mending systems is the right approach to learn something new.

As the founder of a custom software shop, most of our projects were from scratch to begin with so we never really got a large sample size of projects that fit the profiles above to make rebuilding decisions on.

However, there is a very clear case study we can do on a project that clearly warranted a Mend approach. We took said approach with great success. I’m going to outline the project itself and what we did, and try to find characteristics we can apply to other projects when deciding if Mending is the proper decision over a Bulldoze.

The client came to us in a state of chaos. Their Web Platform (LEMP stack) was handed to them by their previous development team with severe performance issues on top of a laundry list of bugs and issues with the code structure, style, and readability. At first glance we definitely thought a rebuild was necessary and were prepared to present a strong case to the client for this.

But then I thought, we might as well do a full code audit and figure out if we could get this thing performing well and written cleanly without rebuilding the stack. The environment, deployment, and data layer setup was (in my opinion) really good, so why scrap all that?

The code audit and stress testing we did revealed that in fact there were way too many HTTPRequests and too many inefficient requests being made on the app (primarily 1-page app), as well as very inefficient UI manipulation in their JS. Those were not underlying structural concerns, so we were able to fix those in the context of the ‘old’ codebase.

In addition, the only other worries about not rebuilding were eliminated quickly when we realized that the file structure and organization of the code, including classes and namespaces, could be easily moved around with minimal effort; AND that the code was fairly modular so cleaning up the readability and style/commenting was no problem.

So for now, it seems like doing a thorough audit of a codebase of a lagging project, by someone completely different than who built it (and with no oversight or input from those who built it — worthless without this caveat due to ego) is the best way to determine if we should Mend or Destroy&Rebuild. 

You can find software shops or consultants to do this pretty easily, but getting actionable feedback instead of just insults aimed at the previous developer (and I am 100% guilty of that in my past) is hard to come by. We are 0% guilty of that now though, so feel free to hit us up below.

sreenath@flow-enterprises.com | http://flow-enterprises.com

This was also posted on our blog.