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.

The right DevOps Structure

Once your company has decided to adopt DevOps, that’s when the hard work actually begins. Typically Development and IT-Operations are separated organizationally. How do you bring the two together? What’s the best approach for your company and how do the different approaches compare to each other?

All those questions are non-trivial to figure out. For me, the work of Matthew Skelton and Manuel Pais really helped me to bring order to the various patterns and anti-patterns that exist.

I highly recommend you take a look at their work:

devopswebsite

http://web.devopstopologies.com/