I started my IT career as a software developer when I was sixteen years old. Back in 1981, Applesoft Basic was pretty cutting edge, and I learned everything by trial and lots and lots of error. In the end it did what it needed to do, and I got paid enough to buy a skateboard which made me deliriously happy. Fifty bucks in 1980s money was pretty good for a teenager, but in retrospect, I was horrendously ripped off, but I reckon the company that paid for my program probably got their Karma.
The code I wrote was horrible sloppy spaghetti code, like a pair of worn jeans that was more patchwork than pants. It wasn’t until much much later when I was nineteen and I had to maintain code that I inherited and increasingly wrote, that I learned about the benefits of what would later be called refactoring. Back then though I just called it “re-writing a pile of crap so it would work”.
About a year ago, I read about “Technical Debt”, in Martin Folwlers Blog Post
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
That concept stuck in my head and rapidly became one of the lenses through which I viewed the world not long after I sold my house. Moving to the new place involved sorting through a decade of accumulated “stuff”. As we began the packing process, we wanted to make space for a cleaner, simpler life. Unfortunately the best laid plans of mice oft go astray, and by the time the moving truck came we’d run out of time. No more careful consideration of what “stuff” to keep and what to throw, it all went into boxes, washing baskets and the back of the people-mover we affectionately called the TARDIS. In the end a lot of the mess we wanted to leave behind came with us.
After we’d set up in the new house, you’d be forgiven to think that we’d succeeded in ridding ourselves of the dross. The place looked fantastic, but there were two rooms and a self storage facility full of “things to sort through” that to this day, still remain a work in progress. Every time I went to look for something in one of those rooms I was reminded of those “interest payments in extra effort”. It didnt take long before the time sorting through the haystack of stuff looking for valuable needles outweighed the time I saved when I moved, much to the annoyance of my beloved wife.
During one of those haystack dives, I remembered feeling exactly the same way about a software rewrite I did back in my twenties. The user interface looked great, but we ran out of time, and I had to quickly port all the messy hidden subroutines that I knew would cause all kinds of grief later on, which they did. It took me another two years to find the opportunity to clean that code up, which I only did because I knew I’d be leaving, and I didnt want to foist that pile of spaghetti on anyone else.
Those two experiences were so parallel and seemingly interconnected that I started looking to see if this technical, or as I like to think of it now, organisational debt, was affecting me in other areas. It didnt take long before I found it in almost every aspect of my life.
- Local Filesystems and Cloud Drives
- Task Lists
- Evernote and OneNote
- Mental Processes
I can track this back to having some really bad time management practices throughout my 20’s and 30’s which led me to be constantly time poor. Since then family, career, mortgages and a series of short term decisions each incurred additional organisational debt. It’s now so bad that it has seemingly made it almost impossible to pull myself out of this vicious cycle of short termism. Yes I know there are great techniques like “Getting Things Done”, but I’ve had that book for about a year, and I’ve only read the first three chapters. I started to beat myself up about this until I realised that this wasn’t just a personal failure, it was endemic in almost every individual or company I came across.
It’s been a long time since I wrote code for a living, so I can hardly call myself a developer, but I suspect that techniques like kanban and scrum we’ve evolved over the last decade to deal with technical debt in software development can be applied at a much more personal level. I also suspect that applying financial models for managing debt both from a business and personal level will also help me make this transition, because the way I look at it, Benjamin franklins “Time is Money” seems like it’s not just a warning about opportunity cost but also an opportunity in and of itself.
If you’ve read this far and have applied things like personal kanban or other software or financial engineering techniques to solving your time management challenges that can shorten my path, I’d love to hear from you in the comments section.
If believe that if I can solve this problem for myself and write about the process I can help others to do the same.
Thanks for you time.
John (Ricky) Martin.