Thousands of errors!

Question

I was assigned to a new project recently. Well, an old project actually, written in classic ASP. Now a new version of the application is being written in the latest ASP.NET, but it's not expected to be RTM in a while (estimated release date is January 2017) so I have to perform some maintenance on the old application until it can be discarded.
Also, I've got a feeling that not all customers will be switching over to the new program immediately, so this version will probably be around for a while.

And the problem is, it's full of errors. Parts of it date back to the previous century, when there were no web standards, and I don't really mind about Quirks mode, and width and height attributes instead of CSS, tables used for layout, framesets etc, but oh, all those errors! width="20px" all over the place, onchange="javascript:...", and in those places where they do use css, style="width:20" and style="width=20px" are commonplace. Not to mention plenty of lines where there are contradictory width and style attributes. Etc etc.
As a result, the web application only runs under IE, and only in compatibility mode. It's clear that the developers never looked at code validity, only if what came out looked like what they had in mind it should look like.

And I don't know how to handle that. I find it impossible to close my eyes to those errors while looking in the code for other errors.
I can of course do a global find and replace to get most of the issues out of the way, but that would mean my first commit would consist of thousands of changed .asp files. Can I do that?

Answer 1

It sounds like you are confusing several things into the term "errors"

• legacy html attributes
• coding style
• coding errors which don't cause bugs
• unreported bugs
• mistakes which are now features
• reported bugs
• reported bugs you have been assigned to fix

On a legacy app which is going to be replaced only one of these types of error should concern you. The last one.

I would go as far as to say you shouldn't even refactor other stuff on a feature you are bug fixing, mainly due to :

• mistakes which are now features

You can see from the code how it was maybe meant to work but never did, but all the users have been getting along with the indeterminately widthed element for the past 10 years and they wont thank you for fixing it.

On the plus side, if you put your cynical JFDI head on, you will be able to burn though the bugs super quick and the new version team wont be able to keep up with the old versions features.

This will give you a wry gloating smile of ironic glee as you recommend a chrome plugin ie6 emulator to clients so they can keep using the marquee 'feature' they love

Answer 2

What you ask is not a technical question, and nobody here can answer it.

You are working on a piece of software in maintenance mode, and you observe out-of-fashion technology and a large number of imperfections and inconsistencies. You ask what to do. Should you for example extend effort to make it cross browser compatible? Should you bring it in line with modern standards? Should you fix syntactic inconsistencies across the app? The thing is, these are business decisions. You should ask your manager or product owner what problems they want you to solve and what their priorities are. Since there already is a project underway to rewrite the app, management is most likely already aware of the problems you observe.

If the app will be full replaced in a matter of months, it is likely they only want you to fix specific critical problems and leave the rest of the mess alone. But we don't know.

You ask if you can make sweeping search-and-replace operation across the codebase, changing thousands of files. Of course you can. The question is if you should. Such sweeping changes will likely require extensive testing to ensure nothing broke. Again it is a business decision if the benefit outweighs the cost in time and risk.

Answer 3

When the application will be replaced in 18 to 24 weeks (adding the to be expected delays to the 6 to 8 week estimated presented above) then you really need to ask yourself what value you add to the business by still investing considerable amount of work in the old version.

Sure, when you would be stuck with supporting the application for several years to come, then getting rid of the technical debt can be worth it in the long run. But when all of it is going to be dumped anyway, then why bother? Just add another hackish fix on top of all the other hackish fixes to repair whatever problem simply can't wait until the release of the new version and call it a day.

You might also ask yourself what you can do for the application in the little lifetime it still has left. When you are really bored right now and simply have nothing better to do with your time you could give it a grand overhaul and remove all the style problems you mentioned, but it is very likely that this will at first break more things than it will fix. You might be able to get rid of these new problems eventually given enough time, but you don't have that time.

Answer 4

Reasons NOT to make big changes:

One: The code is going away in a few months. Would it really be worth the company's time for you to spend 5 months fixing a system that will then be thrown away 1 month later? Caveat: Systems rarely go away when they are schedule to go away. The replacement system is almost always late, there are users who cannot upgrade for whatever reason, etc. But this is a complex issue.

Two: If you make a lot of changes, especially mass search and replaces, you will introduce bugs. Not you might introduce bugs: you will. Suppose you did an S&R and changed "width=200" to "width:200px". Is there C# or VB code on your ASP pges? Because if you had a variable named "width" that you were setting to 200, you just broke it. (Or for that matter, did you think to limit the S&R to ASP pages?) Or if you changed "width:200" to "width:200px", what happens if there was one place in the code that said "width:200mm"? Now it says "width:200pxmm". Okay, let's suppose you thought of those. What if there's someplace that had the invalid width specification, which is of course ignored, and it is now laying out quite nicely. You "fix" the width and it now lays out with 200px ... and the display is screwed up, because 200px is in fact the wrong width to give and it only worked because that value was ignored? Mass S&R's are very dangerous, because you are almost certainly not studying every place you change. You likely aren't even sure what to test.

Three: Code that is "obviously" wrong may in fact be what the user wants. I've seen plenty of requirements specs that call for behavior that is obviously wrong and insane ... and then I go back to the users and ask what they REALLY want, and it turns out that they really want this insane behavior, because that's how their business works or government regulations require it or whatever.

Even if the behavior really is wrong, maybe users have come to expect it and they routinely work around it, and by fixing it, you will break their workarounds. Example: I work on a system where we have a place where you specfy from and through dates that a sale is available to the public. Both dates were really the midnight that began that day, so if you said "through July 30" that meant it ended with the end of the day July 29, i.e. one minute before 12:01 am July 30, not the end of July 30. At one point I fixed this, but I could only do that because there were less than half a dozen people with authority to use that screen, and I could simply tell them all that I'd fixed it. If there were hundreds of users, and they'd all figured out by now that you really had to give the day after the through date, then my "fixing" it would have broken it for all these people.

Answer 5

I can of course do a global find and replace to get most of the issues out of the way, but that would mean my first commit would consist of thousands of changed .asp files. Can I do that?

I don't see why not. A commit should be conceptually one thing, but I see no reason why a global find and replace from style="width=20" to style="width: 20px" would not count as "one thing", conceptually speaking. And if it would help you sleep better, save you being distracted as you fix other things, and not muck anything up, why not?

Answer 6

Your problem is setting priorities: Which of the issues are showstoppers (in production)? Which are ticking timebombs? And which can be left in a while longer (because it works and has done so for years now, even sort-of)?

What I would do in your situation is would make lists of problem classes that I would like to look at. E.g., replacing style="width=(\d+)" with style="width: \1px" (which can probably be rectified with a global find/replace using regexp - sorry if mine is not 100%) would be one class, and if there's just one occurrence, so be it. For each category list a priority (how urgent is it to do this) and an estimate of work (how long will it take to do this category).

Your maintenance tasks will also figure in this list. Now you are starting to apply some management, even if only to yourself, and you have a tool to use when you have time on your hands and nothing to do, or when you need to negotiate with your manager about work to do (or request time to be allocated to something that he might not be aware of). (This sort of proactivity might help you to get noticed for promotions, if done right.)

I guess you enjoy programming because you have a slight perfectionistic personality to some extent. BUT in a commercial environment, you need to start to realize that perfect is the enemy of good (and good brings in the money, perfect might not necessarily bring in noticeably more for a whole lot more work). First do what is needed, then do what is nice to have. Yes, this might go against your grain no end. Just grin and bear it, and perhaps get a hobby to exercise your perfectionism and keep you sane ;-)