The Problem With Quick and Dirty

The last couple of weeks have been pretty busy. Privately our little daughter is rightfully consuming a lot of time and also we have been in the final phase of planning our big garden project which now will commence in May. For work, I’ve been traveling a fair bit being in the US now the second time in a month and on top of that was in Prague last week. Besides that, we are entering a time of change, which is good, but also intense.

I want to keep my schedule with posting something every Monday 6pm and really today I only will manage it with a cheat. I definitely missed German time 6pm, but I can still make Seattle time 6pm!

Recently on Twitter, I found this quote:

“The problem with quick and dirty is that the dirty remains long after the quick has been forgotten” – Steve C. McConnell

Steve McConnell is the author of Code Complete which you can order on Amazon (affiliate link)

It is a book full of wisdom for programmers and one of those books that I like to have a hard copy of. Its content remains true for a very long time.

Back to the quote: „Quick and Dirty“ is so appealing when you are acting under constant time pressure. Everybody seems to be happy at first. The developer can move on to the next task and the product owner gets the feature, extension, bug fix or what-so-ever quickly.

The problem is that just after delivering the item the next urgent thing is lurking around the corner and the quick win is soon to be forgotten. What remains, however, is the hack. Worst case it will cause a bug in future because of unconsidered use-cases or untested side-effects. Best case it will make your system less maintainable, less performant, less readable, less extensible, … the list could go on.

The collection of hacks that your system is built on over time when you have delivered too often „quick and dirty“ is going to make it harder and harder to maintain and extend the application. It will become more error-prone and you will deliver slower and slower until you eventually will have to go into a painful and resource consuming rewrite of large parts of your application.

Don’t be tempted by quick and dirty. Try to do things right and you will be faster in the long run. Constant investment into the architectural health of your system will pay off.

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.