The clock on the mantle is ticking. I have a little bit less than an hour to meet the challenge of writing a blog post for today. I have sat and thought. I have watched TV, an interesting documentary with Josh Gates joining searchers for living specimens of the Tasmanian tiger. I’ve read Dave Winer’s blog posts for the last couple of days. I’ve read Alec Nevala-Lee’s blog. None of them have inspired a topic.
I am no longer daunted by the blank page. I am confident of my ability to fill it with words organized into coherent sentences and paragraphs. But until I can sit down and write something more or less on demand, I won’t have gotten my mind around the process of blogging.
When inspiration comes, or rather when I track down it’s sorry ass and shoot it in it’s tracks, I do a fair job of transforming it into good, coherent narrative creative-fact or fiction. I even write an occasional piece reminiscing about my childhood.
But nights like tonight, I struggle to say anything of interest. It is Friday night and I have had a rough week. I am learning a new phase of the testing life cycle at work. I am also learning how technical debt can spiral out of control as quickly as financial debt can.
Technical debt is a concept that has entered the lexicon of software development in the last ten years or so. The concept is, you find yourself at a point in a project where you are behind schedule and you have cobbled together some horrific piece of code that somehow works if only just barely. Now that you’ve gotten it working, you know how to go back and clean it up so that it works well but you don’t have time to clean up the implementation and meet your deadline.
So, you ship the code as it is with a promise to yourself to rewrite the ugly code later when you have time. This is fine when you pay your technical debt down regularly and go back and refactor the code that you shipped earlier. But all too often other schedule pressures arise and you never get around to paying down the technical debt.
It’s at this point when another programmer comes from outside the project and in the process of finding their way around the code base they discover all the dirty little secrets hidden within it. The problem is, by now the team in general and management in particular, have learned to live with the ugly code. At this point is extremely difficult to convince them that the code desperately needs the major refactoring that the current level of technical debt calls for.
So the project continues to spiral downward into the mess of unmaintainable spaghetti code that it is becoming until eventually someone decides that it would be more cost effective to rewrite the whole project from scratch than to try to refactor the existing code. And they’re right.
Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.