Maintaining Standards During Crunch Time

  |  323 Views

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.

About the Author

Dustin Kozlowski is a certified scrum master and certified scrum professional through Scrum Alliance, the largest and most established agile certification organization worldwide. He enjoys enterprise agile transformations and helping organizations achieve a quicker time to market.

Dustin joined Saggezza in 2009 focusing on print and logistics organizations. Since 2016, he has partnered with private equity firm owned companies in the middle market space to lead digital transformations. He has rebuilt three dot-coms to achieve a stronger customer focus through social integration and drive a 360-degree view of the customer.

Saggezza is a proven technology and consulting partner that delivers personalized, high-value solutions to accelerate business growth.

Share This
Related Articles
A Day in the Life of the CCM Team
115 Views

C-C-M. Anyone know what that stands for? Perform a simple Google search and you might retrieve a few pages for […]

Data Management and the Struggle to Stay Ahead
66 Views