I was attempting to find a pair of socks today in our laundry basket, and it got me thinking about how bad programming practices can be like finding a pair of socks in a laundry basket full of loose socks.
This sounds kind of hokey, so let me explain further.
The Sock Metaphor
I am the type of person that buys a new pair (or bag of) socks, and puts them right on without a second thought of organization and the consequences of jumping into a relationship with my new socks.
At the end of the day, I remove this pair of socks, throw them in the laundry and continue onto the next new pair tomorrow. For the first few days, this isn’t a problem. I have a supply of new socks that are neatly folded still in their wrapper, and I don’t have to do any extra work to locate and don a new pair.
When it comes time for laundry day, though, I begin to feel the effects of the sock debt that I have accrued. I put the socks and other laundry through the wash, and when they are done, I have a basket full of clothing, including tons of loose socks.
There’s not much I can do to lessen this sock debt from the get-go, but at this point, once removing the laundry, if I do not properly organize the socks, I will end up with a lot of wasted time in the future. When I need a fresh pair of socks, they are no longer paired, and I have to begin digging in order to find an exact match for one of a thousand socks.
Eventually, I will begin to build up a vast amount of socks, and it will gradually take over a large percentage of my laundry, since I have not prepared, and would rather go find an already matched pair of socks from the drawer.
Had I simply sat down and powered through the pairing process before needing to wear a pair of socks, neatly tucking the pairs into the drawer for easy access, my time in the future would be much better spent on more important activities.
Programming Application
A novice programmer tends to jump right into the software they are creating, without a second though to the intricacies of what will be involved in creating the product from the ground up. Without a particular vision of how the software will work, and how much effort needs to be expended in order to get things in working order, jumping into the coding process will cause the programmer to accrue a technical debt.
As mentioned on Coding Horror, originally written by Martin Fowler:
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
In this metaphor, if the owner of the socks were to plan ahead for the future need of a pair of socks, the amount of time spent searching for a fresh pair could be drastically reduced.
When starting a new software product, it is imperative to go through the process of pairing your socks before you begin. The amount of time spent at preparing the beginning of a project is only a small fraction of the future cost of not preparing.
I’ve come across this many times in my own personal programming projects, and it is a piece of wisdom that only truly comes from experience. The green college graduate who has done no programming outside of strict curricula and guidelines is prone to jumping in feet first, without going through the steps of planning as many aspects as can be anticipated during the development process. No matter how many times a mentor or other friendly software developer tries to drive it into a new programmer’s brain, the concept cannot be fully understood without once having to pay down a technical debt.
Not all veteran programmers are completely free of the curse of technical debt, but there are simple methods that can be implemented in order to reduce the effects of technical debt on a new project:
- Plan, Plan, Plan – The best thing to do is have a clear understanding of exactly what it is you need to accomplish before you write that first line of code. The time you take to plan now will payoff 10 fold in the future. Do whatever you can to sit down and plan out each and every feature and interface button that is a core part of your application.
- Budget Your Time – Once you have a solid backbone of everything you would like to accomplish, estimate the amount of time that it would take to implement each feature.
- Don’t Be Afraid To Remove The Old Socks – When creating software applications, a developer must not be afraid of cutting certain features if they interfere with the overall flow, or future compatibility of their project. Sit down and decide which features are crucial to your application, and cut the rest. There’s no reason to keep socks with holes in them.
- Take Small Steps – You are not going to be able to jump into a new project with the intent of finishing every last feature before version 1.0 ships. It’s simply not possible. After removing all of the old socks, prioritize the features you want to implement, and get started on the first few that represent the core of your application, and get to the others after the core features are complete.
- Do Not Fear Change – Though you may sit and plan out every aspect that you can foresee, there is a 99.99% chance that your final application will differ greatly from your original plan. Fearing the amount of extra work that will arise from the constantly changing specifications of your application is simply not wise.
I’m sure that I’ve missed a few tips along these lines, but putting more of hard-earned wisdom on the web can only be a good thing for those developers who are just starting out.
The next time you begin to plan your next development project, remember that basket full of hundreds of socks that you didn’t sort when they left the washer.
I guess it’s time for me to sit in front of a giant basket of unmatched socks.
