When people say that you can learn to ‘code in a day’, I think it’s like telling someone they can learn a new language in a day. You might learn a few phrases and get a feeling for how it might suit you, but you are hardly going to translate War and Peace into Cherokee after a day’s tutorial.
One concept often skimmed over when learning how to program is “Technical Debt”. Technical debt is a term that refers to all the temporary expedients used when programming a task that help you provide it quickly and allow for experimentation and research but don’t meet basic standards for maintainability, reuse or stability.
Technical debt builds up while you program and must be paid back at some point (generally re-factoring and documenting). If technical debt is allowed to build too high, the software becomes unmaintainable and eventually becomes so bad that it would be quicker to re-write it than fix it.
Technical debt is often overlooked when shipping software, you get the product just about ready, someone sells it and you ship it. Nobody wants to spend any more money fixing things that don’t appear to be broken and if there are too many areas to correct, you won’t be able to spend anywhere near the amount of time needed fixing the things that nobody seems to care about – until the bugs start piling up and someone goes looking for who to blame.
The trick is to regularly factor technical debt into your development plans, you know it’s going to happen, you know it shouldn’t get out of hand and if you allocate time for it (usually after a feature delivery, before the next features are added) then nobody complains about the time it takes and the resources it consumes. At the end of the day, you will have a product that you’re proud of and anyone who ends up looking after it or building upon it will thank you for your effort (sometimes that will also be you, some years/months down the line).
So, why am I telling you this? Well, I have just put together the lithophane utility. It works, people are using it and it’s just a quick hack, so I could move on to the next thing. BUT, there are some things that don’t quite work as I’d like, some pieces of code that I cut and paste and squeezed into the rest of the code don’t comply with the naming conventions or code style I’ve used and there is a big problem with the structure of the code in terms of reuse and readability – much of it is a long way from good practice. I will quite probably re-use much of this code in the next utility, so it’s important that it is a stable platform to work on and as one of the intentions is that people should be able to adapt it, it needs to be readable, well-structured and documented. After-all, we all have to pay the piper.
So for the next few days, I’m going to re-factor and document – pay back some of the technical debt. If I think there’s anything significant in the changes, I’ll write it up for you to read.
