When to rewrite? It's an interesting puzzle, huh? Your vehement lust for just fixing the old stuff once and for likely stems from the fact that you are getting constant resistance to as much. If you could rewrite as much as you'd like you'd eventually admit to yourself that you can't just rewrite ever app every year once a year (or perhaps even more frequently than that). It wouldn't make sense. At some point it's wasteful. I like to build stuff under the delusion that I'm building something that's going to last. If I were to honestly admit to myself that my ice sculpture is ice sculpture it would result in a drop in quality on my part as oh-what's-the-point sets in, warping my hand. That said, there has to be a happy medium between knowing that you're building something to throw away and never doing rewrites. It feels like the pendulum tends to swing closer to the later extreme. If something is working but bad the working part tends to overshadow the bad and the business will be inclined to keep living with a thorn in its foot as today's pain feels just like yesterday's pain and we are used to that and don't sense what we might be missing. So when are we going to rewrite something? I once attended a talk about trying to convince a business that the overhead spent on bad code was more expensive than the cost of a rewrite, but, of course, in those scenarios it is hard to make an argument successfully. Just reference what I just said about the thorn-in-the-paw. I just finished a six month contract in which Angular 2 components were being introduced into a preexisting Angular 1 application, and when we needed a datepicker in the Angular 2 stuff we went through the burden of figuring out how to inject a datepicker from the Angular 1 stuff (which wasn't trivial) in lieu of just using something Angular 2 specific as that way the control would feel consistent with the other datepickers. What we could have done instead was use an Angular 2 control and then rewrite everything that had a datepicker that smelled like $scope if you will, but, as you might imagine, we didn't do that. In this same application we decided to roll our own Angular 2 grid for paginated lists and when it was extended to include exporting to Excel sheets some really awful preexisting JavaScript was just copied and pasted out of an existing control used in the Angular 1 stuff. I tried to clean up what was with something like this, but when it didn't work quickly (and this doesn't work) I just gave up and let the nasty code be.
function makeExcelSheet(guts, name)
var stage = document.createElement('iframe');
document.body.appendChild(stage);
stage.contentWindow.document.open("application/CSV", "replace");
stage.contentWindow.document.charset = "utf-8";
stage.contentWindow.document.write('sep=,\r\n' + guts);
stage.contentWindow.document.close();
stage.contentWindow.focus();
stage.contentWindow.document.execCommand('SaveAs', null, name + '.csv');
document.body.removeChild(stage);
}
I can think of just a few times when I've both seen an effort to rewrite something and have been privy to what is inspiring the rewrite. It's significant pain driving the rewrite, the kind of pain that obviously screams loudly that there is money from sales being lost as long as there is a performance problem. I once worked at a dotcom where I got the seat of a developer who had quit in frustration. This other guy had authored a search feature with a bunch of joins in SQL for a shopping cartesque buy-things-online website that I think also drove the specials on the homepage itself. This was all before bandwidth testing was really a norm. It took twenty seconds for the homepage to load when the site was swapped out an older version of the site in a go live and the sales fell off. This would be an example of where the business, which had been tracking metrics on SEO traffic and sales, could clearly see a decay, an easy to quantify problem. This is not the same things as the development staff vaguely telling you that things could be better. Instead metrics that will make their way up to the highest stakeholders, which cannot be hidden from, are telling you there a problem. It's no longer the peons below who insist on change. It's the gods above. See the difference? What do you do? Throw away the new web site or fix it not wanting to believe you wasted your money on the development? The second option is going to feel best when you are already on fire and trying to do damage control. The CEO yelled at the guy before me, and, well... I got a job when he bailed. I didn't fix the problem myself though. At the time I wouldn't have even known how. Another party brought in to oversee me and other development turned this around by using a denormalized schema to sidestep the SQL joins which were so expensive. Specifically, SOLR was used. The twenty second time to load the home page became three seconds. Things got good again. Then the CEO was fired as a scapegoat. When a CEO is fired, that should suggest that there was more pain than a yeah-yeah-whatever may counterargue. Another example I can give has to with the Angular 1 app into which Angular 2 components were being placed. In that scenario, chunks of the Angular 1 stuff was getting rewritten as Angular 2 components in the name of a performance improvement. Remember that Angular 1 has a memory leak in it. The application in question is a call center app through which millions of dollars of revenue stream so any lag or performance problems punch the owning company right in the wallet. The cost of having developers try to improve the app is miniscule compared to the gains to be had and this again is a problem that just bleeds up to the highest levels of the organization and cannot escape the eyes of oversight or be easily dismissed. A rewrite suggests there is something big obviously wrong for all to see if you're going to go there. You're visible in the reflection.
No comments:
Post a Comment