Social Icons

twitterfacebookgoogle pluslinkedinrss feedemail

Wednesday, November 18, 2009

Why "Quick and Dirty" is bad for software projects

Anyone whose ever worked on a software engineering project has at one point or another either said or done (or both) "let's just implement something quick and dirty for now and we'll fix it later." While I've been living through the nightmare of this statement for the last 2 years at work, it just hit me today as to why this is so bad.

A co-worker just asked me if I knew what the c-rt.tld file was about and why it was only referenced in one JSP page. It struck me almost immediately what that file was and even though I'd seen it before, it never clicked until now. We opened it up and as expected it was a JSTL tag library definition file, in this case, for the core library. Now, we also have a c.tld which also defines the JSTL tag for the core library. Diffing the files yielded that the JSTL versions were slightly off, but that other than ordering, the files were the same. Looking at the SVN history made it all clear.

First, a brief background: in late spring 2006 my company hired a non-American subcontractor to implement a rather large and important piece of functionality for our web application because at the time, we simply didn't have the resources to do it in house. They initially branched our code and went at it while we did our own thing in our existing code branch. According to the check-in comment for this c-rt.tld file, the file was added as a result of the merging of these branches some 6 months (!) later.

My guess as to what happened is this: the developer for this check-in ran into conflicts the likes of which even god has never seen and instead of trying to understand the conflicts and why they were occurring, they just created different versions of the file and "fixed" the references in the @taglib directives in the JSP pages. The result is that instead of only having one TLD for the core JSTL library, we have four(!). Likewise, we have four for the fmt library and three for each of the sql (which you should NEVER use, by the way, and we don't) and xml JSTL libraries.

I realize that this example alone doesn't directly state why "Quick and Dirty" is bad, but consider this: We fired said subcontractor in December 2007 and we've been cleaning up, rewriting, and removing their code ever since. This means that we've been working on fixing issues with their code for longer than they were even contracting for us.

So, the next time someone on your project says "let's just do it the quick and dirty way for now," push back, put your foot down, and say "no." For better effect, replace "no" with "over my dead body." If you're overruled, and this is bound to happen, file a P1/Severe bug against the code fully documenting where in the code the egregiousness lies, why the decision was made to not do it correctly the first time, and the right way to fix it. Trust me, you think you won't forget, but you will - and the bug documentation is all you will have.

2 comments:

  1. Addressing the issue of lousy subcontractors/developers, reviewing code check-ins for new developers has proven useful weeding out this type of issue. Give it a try. Next time you have a new developer, take 10 minutes each morning reviewing their check-ins. It's amazing how quickly their skill comes through.

    A strategy to help mitigate the impact of quick and dirty involves defining a decent interface to the component. Trying your best to at least get a decent interface into the mess helps when the time for refactoring comes around. Because we all know, quick and dirty is inevitable. Which I believe is a driving force behind agile and the refactor mercilessly attitude.

    ReplyDelete
  2. @steve

    You're absolutely right. Unfortunately for us, we were severely understaffed in engineering and each of us had way too much on our plates so that after a week or so, we stopped code reviews.

    Now, 3 years later, we're still exorcising the code as we can. One of my teammates likes to describe their code as the scene at the end of the movie where there's the shot of a grave with a fresh mound of dirt and as the people walk away, a hand reaches out from the dirt before the screen fades to black.

    Their code really is the gift that keeps on giving.

    Thanks for the post.

    Oh, and for new engineers, we're so picky in the hiring process that, to my knowledge and observation, it's not been an issue - though I will occasionally find points for teaching moments.

    ReplyDelete