Monday 28 February 2011

Just a quick fix, just a quick fix, boom! Game Over Man!... Game Over...

What are these quick fixes? Are they the start of the end? Or is it already too late, as when you've found there are a few quick fixes, does that mean there are thousands of them in already, more than likely yes!

What causes them?

  • Friday afternoon? 
  • No time as other things are important to get done? But what is more important than the current fix you are doing, if you have to rush it to get onto something else, then don't do it!
  • Because it doesn't break any unit tests? Are then the tests written correctly, if they are stopping quality being writing?
  • Is it the lack of pride and care in what one is doing, or any thought for one's colleagues as one is not going to be around long enough when these fixes come back to bite you in the ar!*e!

All these questions and no answers, not sure I can give any answers yet, but if I find some I will surely post back here.

Is this what agile is? Do a fix in the first place you can see the easiest place? Or is it to refactor code into the correct places to fix the issue, maybe its neither?

What do the sum of these quick fixes add up too? I tell you what! A bloody mess of looking at random, undocumented code here, there and everywhere, slow down of progress, and skewed estimations. Code spread, where these fixes are not structured in the correct layer! More than likely more fixes will be required to fix the fixes! Superb! That's some special mess!

Are developers being continuously squeezed to write code to be “finished” rather than “completed with quality”? Or do developers wear blinkers and only see progress as a happy product owner? Is there a way to prove this?

Time is always squeezed and quality drops! This will inevitably get worse over time ‘Mr Anderson’…
Well commented code, we hopefully don’t need too most of the time (well you shouldn't so much) as the code is readable (isn't it, you good coders you), but the more quick fixes (I suspect highly uncommented)… ...who knows what randomness is being produced.

I guess there is a time line where the quick fix is fine, for a small, completed, un-evolving project. Are there such projects, really?


I recently came across an interesting article and I haven't looked into it yet, but could be very interesting. Convincing team members that something is a good idea.

1 comment:

  1. Quick fixes always have a habit of becoming permanent. I try to avoid them always, with everything I do. I rather leave a problem until a solution is found. At least then you know what your problem is, instead of forgetting all about it and let it bite you in the ass months later...

    ReplyDelete