Matt Heusser and I were discussing his upcoming
Workshop on Technical Debt, at which I hope to be speaking in August, and we came up with several interesting ways that technical debt is created.
Hacks create technical debt by ignoring principles of good software development in favor of quick, easy fixes
This is the obvious one because it is the one technical teams complain most about. “I didn’t want to do it that way, but my manager said I could only choose from options that took less than a day to implement,” or some variant of this statement, is the most common answer to the question “Why does X suck so bad?”
So how do developers typically fight back against hacks? With reuse anticipation. Now the bad news.
Reuse anticipation creates technical debt by expanding the supported code base without creating a correspondingly timely value proposition
It’s easy to imagine that the service, component, module, whatever, that you’re building might be used by multiple applications in multiple ways. It only takes an extra YY hours to make it universal, you tell the project manager. And then we’ll never have to write this code again. Sometimes, when you already have “universal” demand for a component, this is a good idea. It’s also a good idea when it is a very specific, low-level technical capability, like dumping a message in a queue or searching a string for a value or something like that. Sometimes it’s a really bad idea - over-generalizing a capability can make it so difficult to “reuse” that no one will reuse it. Either way, it increases your technical debt, because whether anyone reuses it or not, the code you have to support is more complex than it would otherwise be.
Time creates technical debt
There’s a great riddle in The Hobbit, by JRR Tolkien:
This thing all things devours:
Birds, beasts, trees, flowers;
Gnaws iron, bites steel;
Grinds hard stones to meal;
Slays king, ruins town,
And beats high mountains down.
Tolkien might have included code in this list had he been a software developer.
Time has a way of dimming our memories of the code we’ve written, what it does, and why it does it. It is for this reason that development teams often turn to comprehensive documentation to save them.
Now for more bad news.
Comprehensive documentation creates technical debt
Every document you write that has more purpose than helping you figure out how to deliver code NOW becomes another artifact you have to maintain. It adds to your code base in that regard. Now, instead of paying people to maintain the code, the business has to pay someone to maintain the code and the documentation. You just fell further behind.
Documentation typically only has ROI in the short term. It is a very rare document that provides value over the long term. Usually it very quickly becomes a cost with little return of any kind.
Innovation creates technical debt
Einstein said we can’t solve our problems with the same thinking we used when we created them. Sadly, when we continuously apply the same thinking to our code base that we used when we created it, the technology world doesn’t do the same. It moves on, finding better ways to do the same thing. Small changes add up and become big changes, and suddenly there are much more attractive technologies that we can’t use because we’ve fallen so far behind.
When we see the world moving on to bigger and better ways of solving our problems, it’s tempting to say something like this:
“There’s no point putting effort into X, we’re just going to move to Y soon anyway.”
Sometimes this is a good idea, if moving to Y is funded, approved, and making progress. But if Y isn’t approved, giving up on X will only increase the amount you owe, and you’ll feel doubly bitter about it when Y never materializes.
When I see this problem, I think of a line from an old song: “If you can’t be with the one you love, well then, love the one you’re with.”
Technical debt creates more technical debt
With credit cards it is sometimes possible to make the minimum payment without reducing your principal a penny. In fact, you can pay your bill and end up with a higher balance because of this.
It’s the same way with your code base. If you don’t invest in it faster than you are accruing technical debt, your technical debt will grow. Why? Because you don’t have time to make it better, so what are you doing? You’re hacking - cutting corners and doing the wrong things just to get done in time with the resources you have.
Technical debt sucks as bad as credit card debt. I suspect that paying off technical debt is very similar to paying off credit card debt. It’s hard, it requires frugality, and it means shedding everything that isn’t really important. More about that some other time.
Have a nice week.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: Architecture · Information Technology Trends · Project Management
I’ve been using the Selenium IDE as part of my exploratory testing sessions lately, which, if you don’t know, is a testing tool that records my interaction with a web site, allows me to replay it automatically, and also lets me export it as automated tests in various coding languages (Ruby, in my case).
Unfortunately, the format of automated tests I want to create is not supported by the Selenium IDE. The Ruby script it generates is for Unit::Test, not RSpec, which is the format I want. So over the last week I’ve gotten pretty good at generating the Unit::Test code and converting it to RSpec so we can run it in a headless grid integrated with our CI environment.
But I’d rather just export it as RSpec directly and skip the whole conversion process. As it turns out, it’s pretty easy to add a new exporting format to the Selenium IDE. So I did it, by modifying the code that creates Ruby - Unit tests so that it will create RSpec code instead. It only took about ten minutes to do, and the end result isn’t 100% perfect, but for most of the testing I do it will generate RSpec code that will run right the first time.
I know Selenium/RSpec doesn’t have a huge user base at the moment, but if anyone would like to download the file, here it is. I’m not reserving any rights to this - do what you want with it, use at your own risk. To install it, open the Selenium IDE, pick Options=>Options. Click on the formats tab, then the add button. You will see two fields, one tiny, one huge. In the tiny field, type Ruby - RSpec. In the huge field paste the entire contents of the file OVER the pre-populated stuff.
Now, whenever you export a file, Ruby - RSpec will show up as one of your choices. Cool, eh?
If you make improvements to this file, please let me know. I’d like to benefit from them as well. One of the things that would be cool is if I could create describe…do and it…do blocks from the IDE. That would probably require a combination of extensions and changes to the format.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: Exploratory Testing
Today is my 35th birthday. It doesn’t feel particularly old to me, but it does feel like a milestone. It feels like I was supposed to have done something with myself by this age, that I should be more than just a tiny little cog in a gigantic, complex machine. I think it’s natural to feel this way at some point in your life. For some people it may be thirty, forty, or fifty. For me, it’s thirty-five.
This feeling intensified when I recently listened to the audio version of Randy Pausch’s epic book, “The Last Lecture.” A computer science professor dying of pancreatic cancer, Randy gave a “last lecture” for Carnegie Mellon University that went on to become a YouTube hit and will undoubtedly be a best-selling book, if it isn’t already.
One of the themes of Randy’s book is dreams coming true. He talks about the dreams he had as a young boy, and how some of them happened and some of them did not. It was a very emotional section for me - I can’t really remember what I dreamed of growing up to be when I was six years old. I’m pretty sure it wasn’t to be an IT project manager in a corporation with revenues higher than the GDP of some third-world countries. I finished the book with the distinct feeling that I needed to find a way to make my professional life mean more, to myself, and to the IT community at large.
The Last Lecture is a book that will make you think about what you want most out of life - your job, your family, your marriage. It will make you wonder what you would choose to spend your time on if you were told you only had six months to live. Would you ever show up at work again? What would you tell your family? How would you create their last memories of you? What childhood dreams would suddenly come bubbling to the top of your priority list after having been ignored since your age first became double digits?
It’s impossible to read this book and not ask these questions. It is simultaneously heart-breaking and heart-warming, and forces a re-evaluation of everything you ever thought was important. For me, it sharpened my desire to do more with my professional life, so that when I turn forty-five I will be able to look back on the third of my adult life I have spent working and not feel like I should have done something else entirely.
Read or listen to Randy’s book. Or just watch his lecture on youtube.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: Books And Movies · Uncategorized
I thought a Blackberry would make me more productive, that it would help me keep on top of the email inbox battle.
I was wrong.
I have fallen further behind on my inbox than I have ever been in my entire career. What the heck is going on? I have email at my fingertips, anytime, anywhere. Why can’t keep up with it anymore?
The same is true of every person I know who has a Blackberry. They are the slowest to respond and have the deepest inboxes of all my colleagues.
I think the problem lies in the interaction between my Blackberry and my desktop inbox. I can’t file emails after I respond to them on my Blackberry, so I have to do double maintenance. I read and respond on my Blackberry, forget what I did, then do it again on my laptop hours later, except that I don’t respond again (hopefully). But I do have to read the email, notice that I already responded, and then file it.
My solution to this is to resist the urge to use the Blackberry as an email tool, which sort of defeats the purpose of the product. I am trying to use it solely as a phone and calendar tool, and ignore the email except when I am traveling.
It’s not working so far. I can’t help checking my inbox. It’s like a drug, and even though I know it makes keeping up harder, I check it anyway. I need an intervention. I wonder if there is a self-help group I can attend…
Ironically, the blackberry is great for checking gmail. It works just like the browser, pretty much. It rocks.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: Information Technology Trends
Tuesday night I spoke at XP Western Michigan, an XP user group in Grand Rapids Michigan. Here’s a link to the presentation - “Pulling Your Head Out of Your… Budget: Mental Re-tooling for Agile Project Management.” It was a great time - thanks to XPWM for having me out and to Matt Heusser for introducing me.
While I was there I was lucky enough to meet Carl Erickson, one of the owners of Atomic Object, and check out their office in Grand Rapids. It’s hard to think of what I saw there as an office - it had more in common with a grad school lab than an IT department. I thought it was awesome. One of the first employees to greet me was Carl’s dog, a friendly blue-eyed boy with a rather frightening resemblance to a wolf. Not only was he very well-behaved and quite used to strangers visiting their lab, he’s a perfect example of what you’re not going to run into in your typical corporate IT office building.

There are no cubical walls at Atomic Object, nor are there any offices for “The Boss”. In fact, the office was just a big, enthusiastically messy and non-sterile open space, with desks scattered around the room almost randomly. A hodge-podge of computers covered the flat spaces, most of them macs, nearly all of them with multiple monitors. One of the developers was even pounding away at a Macbook Air, the first I’ve seen in the wild. [Read more →]
If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: Funny Things · Uncategorized
A few days ago I overheard someone talking about outsourcing. At one point, they said “it’s hard to outsource innovation.” I couldn’t help snickering at this - it’s probably just as hard to insource innovation. In fact, it may be harder.
Corporate IT is, by its very nature, a barrier to innovation. This is true at many levels, starting with your management chain. How many layers of buy-in are required to try something new? What if you actually have to buy something to try it? Hierarchical organizations make innovation harder because they impose a decision-making layer of bureaucracy upon the innovators.
[Read more →]
If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: Project Management
Eleven years ago I sat behind my first post-college desk. On it sat a Sun SPARC 20 workstation, a powerful Unix machine, with a 21″ CRT monitor above it and a 3D input device beside it. I don’t remember what the input device was called - it was a round ball you could push, pull, twist, and shove in any direction. It was hot - far more powerful than anything I could purchase on my own - a veritable CAD monster. It was disappointing to return to my crappy little I-just-got-out-of-college-and-can-barely-afford-the-rent apartment and see my Sony Vaio with it’s 15″ CRT beside it. I would have rather stayed at work than use that thing.
This was typical back then, in the good ole days. Work hardware was almost always better than what you could afford at home.
Things have certainly changed since 1997. Check out the system that graces my home office. Sure, I use it for blogging, writing, and the occasional freelance testing gig, but aside from the second monitor it’s not very different from what an average citizen of the IT world has at home.
Now compare it to what you have on your desk at work. Do the words “fully depreciated” come to mind? And where’s your dual monitor? Never mind the decades of research that have proven how much dual monitors increase productivity.
No wonder kids don’t want to study computer science in school anymore. What is IT going to do to attract people who like tech toys if IT doesn’t have tech toys anymore?
If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: Agile · Uncategorized
You are going to spend a lot of time at work. This is especially true early in your career as you use youth to outpace others. The ratio of women to men is increasing as more and more women join the workplace. Companies encourage teamwork, honest communication, and after hours interaction. Most work environments bring together people who share your economic, social, and education level. Those dynamics are combined with being young and passionate with a new steady source of income. It is a bittersweet recipe for romance.
Most advice regarding office romance will tell you to be discreet, steer clear of your managers and subordinates and review the HR policies. That advice assumes you are going to stay with a company and can successfully navigate the political hailstorm you will fall into. The better advice – advice that is both easy and foolproof – is just don’t do it.
Don’t do it. You will want to, but don’t. What about that really cute girl who flirts with me? Don’t. What if I really dig the guy in accounting? Don’t. What about my manager who says he can “take me far”? Really don’t.
Below is a handy chart for when to pursue your office romance

The fact is office romance is prevalent. So is surfing for porn at work. The best advice early on is to avoid both. You may find a date, but you’re not likely to find your soul mate. In the mean time, you will have to deal with increased HR scrutiny, jealous coworkers, office rumors, productivity losses, suspicion of favoritism, potential career damage, loss of power and the threat of sexual harassment lawsuits. And that’s only if you’re dating.
DJ1.0 is a contributing editor of TechDarkSide.com. We don’t know much about DJ1.0, since he participates in the dark side anonymously. You can reach DJ1.0 at dj10@techdarkside.com.
This post was originally published on TechDarkSide.com on February 27, 2007. As one of the most popular TDS posts ever, I thought it was about time to run it again.
~Dave
If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: DJ1.0
If you haven’t seen Alltop.com yet, take a minute to check it out. Alltop.com is a venture of Guy Kawasaki’s that I think is pretty cool. It collects headlines from blogs and other sites based on the topics they cover in an easy-to-browse way that surpasses your regular news sites.
I really like Alltop.com. It’s fun to look through the topics and follow whatever catches my eye. The content they point to is good and new topics are added all the time.
Best of all (at least for me, that is), Tech Dark Side is one of the sites listed on Alltop.com. Cool.
Check out Alltop.com. If you’re tired of news sites that only cover the news everyone is reading and would rather find something you’re interested in, Alltop is for you.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: Announcements
Mike Kelly and I delivered our two-day practicum, “Exploratory Testing in Practice” at Mobius Labs in Indianapolis a few weeks ago. I haven’t posted about it since then, but I had a good excuse - the birth of my son Jake.
The feedback we received on the course was really positive. The 50/50 mix of classroom style learning and testing exercises against production applications seemed to work really well. Many of the participants wished it had been a three day course, and given the chance to reflect on the course a little I have come to agree with them.
Expanding the course to three days will give us more time to get specific with oracles and heuristics, plus we’ll have time to introduce different approaches to managing charters. I think adding another day will really enrich the experience for attendees.
I’m planning to present this course a few more times this year in different cities throughout the US. These events will follow the three-day format recommended by our attendees of our pilot course. The first class will be held in the Dallas/Ft. Worth area from July 15-17. Subsequent classes will be scheduled for San Francisco and Chicago in August and September.
Registration for the DFW course will open on May 1. If you are interested in this or any of the other training events, please send an email to dave at techdarkside with “ETP” as the subject and I’ll send you an email update when more information is available.
I am also happy to bring this course on-site to your location. For details about pricing and scheduling, send me an email with your contact information and we can discuss your needs.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: Exploratory Testing