The other day I was watching a painting competition on TV (I know, my coolness knows no bounds). I must stress that my artistic skills are horrific, and I know next to nothing about art or painting. You may be wondering why I’m going on about painting on a blog that is a purveyor of (what I hope are) helpful software articles.

The contestants had to paint a picture of some sort in a given time, and were judged on their efforts afterwards. One thing that really struct me was that when they were approaching the end of their allocated time, the painters were not rushing even though some still had a lot of work to do.

As I’ve already mentioned, I’m no artist, yet rushing something typically equates to abandoning some level of care in order to complete a task. Had they have rushed, there would’ve been parts of the painting that look obviously worse than areas where more care was given.

Coming back to software development where are allocated time is usually a week, we can sometimes pack in more work than is anticipated. There are times where I have rushed, and I can categorically admit that every time has caused me pain.

When you are rushing to develop a software application, you are only concerned with one thing; get the tests passing and the features complete. Good code however takes time; time to refactor large functions into smaller functions, time to get the right abstractions in place, time to make the code coherent and easy to read. The time spent doing those things makes your code far easier to work with at a later date.

Code that is rushed is harder to maintain because maintainability wasn’t a concern to the developer whom was under pressure to deliver. Say you do rush and you managed to deliver something that worked but the code was not up to scratch, there is a very good chance you’ll be coming back to that rushed code in the very near future. That code is more likely to be harder to work with, and could potentially be thwart with design issues that’ll really affect your productivity for subsequent iterations.

Delivery managers will not agree with this, but when it comes to software development; take your time. Think about the best way to do something. What design would be best. Research ways to improve your productivity. Your code will be easier (and ultimately faster) to work with. You’ll gain that time back at a later date.