Maintaining Standards During Crunch Time
It’s the morning before a late afternoon pitch of a new web application and you (the only front-end developer) have been presented with a last minute list of visual changes that need to be completed ASAP for this meeting to make sure the presentation goes well. What do you do?
You do what we all do. You make every quick and dirty change, even hardcoding values in as necessary to ensure the changes are created as fast as humanly possible to meet the deadline. There is nothing wrong with that; it is what is required to ensure the pitch goes smoothly.
The presentation ends up going well, largely helped by your effort making the needed changes. Everyone goes out for dinner and celebrates.
End of the story? No, unfortunately.
Rarely is the code retired and never used again after a hack-a-thon to get it ready for a presentation. Frequently, developers relax after meeting a tough deadline (I know I do) and allow a couple days or a weekend to go by and forget about the dirty fixes that were put into the code. Development continues until bugs and issues turn up, which turn out to be due to the bad fixes and wastes time.
One of the easiest ways to prevent these wasted hours spent debugging is to put in special comments before you put in a temporary fix. Personally, I have grown accustomed to using one of the following above any temp fix:
10
|
//TODO: Rewrite later to dynamically set size instead of hardcoded value. |
Or
10
|
//TODO: Ensure this layout looks correct on mobile. |
My text editor (TextMate) of choice allows me to search my entire project for TODO comments (ctrl + shift + T), which enables me to go through all of these potential bugs easily and correct them when I have time after the deadline has passed. After a session of quick fixes, I tend to stick a note on my monitor to ensure I remember to go back through the TODOs when I start coding on the project again.
Worst-case scenario, you were too busy to even add in these comments and have to rely on your version control system (which you better be using! If not, go here) to see which files you changed. You will have to spend time analyzing the changes to determine what needs to be fixed, however you should still be able to fix the situation.
For the record, I am not condoning a hacky fix to a problem rather than a dynamic and stable solution. I am only talking about last minute changes when even as you code it, you are thinking, “Gosh, this is an awful way to do this but it works.”
Hopefully everyone can avoid the last minute scramble changing code, but if not, these tips should help you out.