Hacking debt

The term technical debt describes the accumulated effect of short term decisions in a software development process. In order to meet a deadline, for example, a project will take shortcuts, developing code in a way that’s not best for future maintainability but that saves time immediately. Once the pressure is off, hopefully, the team goes back and repays the technical debt by refactoring.

I’d like to propose hacking debt to describe a person who has been focused on “real work” for so long that he or she hasn’t spent enough time playing around, making useless stuff for the fun of it. Some portion of a career should be devoted to hacking. Not 100%, but not 0% either. Without some time spent exploring and having fun, people become less effective and eventually burn out.

Related posts

For hacking financial debt, see this.

15 thoughts on “Hacking debt

  1. “Some portion of a career should be devoted to hacking”
    yes, but in some cases it’s lack of internal motivation, not external pressures. Hackers *make* time to hack.

  2. In my experience it was always the people who will spend a couple hours playing with something just for fun who got the most company work done. The ones who lacked the enthusiasm to work on anything they didn’t have to got the least done.

    As in most things, there’s a muddled mixture of cause and effect. I imagine playing around was mostly an effect: people who enjoyed programming got more done and did side projects for fun. But there’s at least some cause: people who play around recharge their batteries, discover new things, and get more work done.

  3. This is why I always ask candidates I’m interviewing if they’ve done any interesting side projects. Candidates with good or multiple side projects generally are programmers because they love it, and are exactly the type I like to work with.

  4. Dan S: I love that story about Feynman. I’ve followed his example several times when I felt I was approaching burnout and it helps.

    Tony Di Croce: Years ago I read a book by a man who started a private school. When he interviewed history teachers, for example, he would ask what books they’d read recently. If they hadn’t read any history, he’d ask why. He didn’t want to hire a history teacher that didn’t like history.

  5. I love this idea. I find that when I only write code at work or learn technologies related to work, the whole idea of writing software is less enjoyable. I just recently hacked a little web app together over a couple weekends, and I started having more fun at work. I feel that programming is as much art as science, and we need to remember to feed our artistic side.

  6. I fully agree, developers who just slave away 9:00 to 17:00 and then go watch TV usually don’t shine.
    Making time to play with new technology certainly pays off.

  7. Related: An old John Cleese presentation/video on creativity from the early ’90 is circulating the web these days [http://goo.gl/ZMOuK]. He’s talking about creating a good balance between time spent in “closed mode” and “open mode”, where “open” means your mind is allowed to “play/hack”.

  8. Nicholas Ketchum

    Also, the novelty of making new discoveries via side projects, etc., provides fuel to developers during those “work” periods, even if those discoveries aren’t immediately applicable to current work. I’m a firm believer that novelty and motivation are positively correlated, and those who keep “novelty levels” high can push through with the less-novel work more easily.

  9. Nice post, John!

    Ditto the Feynman story, and having similarly resolved burnouts.

    I have a half-baked notion that lack of hacking leads to a deficiency disease, like scurvy or rickets.

  10. Nice Post! Though time boxing is really tricky, sometimes I find it hard to limit the amount of time should be allocated for it.

  11. Oh. I never gave that meaning to the Technical Debt. I thought of it as the fact that, on the long run, technological breakthroughs might turn into debts for the groups or societies that used them first.

    For instance, the subway systems in London, Paris and New York City are now considered as burdens compared to the systems in Beijing or Kuala Lumpur for instance. The difference of costs between the old and modern systems for maintenance, adaptation and expansion are what I thought was called Technical Debt.

    But even with that definition, I tend to believe that similar technical debts exist in the software industry, where you’ll have to pay extra to adapt, rebuild or expand your system to meet today’s needs, no matter how well it was designed and implemented initially.

    Maybe some network guys could come up with example. The TCP/IP protocols, maybe ?

  12. Technical Debt. Interesting. I’ve run into this, been burned by it, but didn’t have a concise term to describe it.

    Does it include decisions that were wrong, but based on one’s best estimate of future technology?

    I could come up with quite a (depressing) list of my incorrect design decisions made in good faith – right now I’m rewriting apps from Xibs to Storyboards, for example.

  13. David Gunnarsson

    Very nice, now I have an expression for what I have for long thought.
    After have been working as a consultant and thus seeing alot of different organisations I can now spot the individuals with high Hacking Debt quite rapidly. Franky working with those individuals are pretty boring, and the engineering solutions tends not to have the same standard of quality as those with broader technical knowledge and still lively technical playfulness.
    Sadly few organisations see this as a real issue and undervalue the benefits of broad know how. This is especially true the more micromanager the boss tends to be (we have all worked with those!).

Comments are closed.