Hacker | Engineer

I’ve often been puzzled by why some hot new technologies or services take off, and others that are similar (or even better) fizzle. Two that come to mind are Arduino and Dropbox. I’ve been working with PIC microcontrollers for years, and I get my chips for free via Microchip’s sample program. Why, then, would anybody pay $30 each? It’s the same functionality, just packaged differently. And there’s the key. Dropbox? I’ve had secure, remote storage for a long time. But now I have a dead-simple way of doing it, and guess what? I use Dropbox far more. Neither of these technologies are new, but both have taken their markets by storm nonetheless.

As a geek, I tend to miss what makes products appeal to others. For this situation, though, I think I’ve cracked it. Many purchasing decisions, especially for free things, are no longer about price. They’re about barriers. The easier it is for me to start using the tool or service, the more likely I am to buy it. Price factors in, but it’s secondary. Both Arduino and Dropbox are pathetically easy to start using, so why not? Even with all of my PIC expertise, I’d rather just pull out and Arduino and get started. With more and more things clamoring for our attention in this century, anything that reduces the time I have to spend on the task is a godsend.

The little things, then, are what differentiate the great products from the truly exceptional. Companies who figure out the key little things to make their product truly easy to get started with and use will often win in market others say is impossible to enter. Apple has demonstrated an amazing ability to hone in on these differences and exploit them to enter markets like MP3 players and cell phones and completely dominate within a few short years. Their products are often technically inferior, but they’re so much easier for the average user that customers continue to stand in line to buy iPhones even today.

If you’re a consumer-facing business, these little things could make or break your entire venture. With “free” web software, it’s even more critical since there’s no price to try and compete on. I certainly don’t yet have the ability to identify these differences before the fact, but anybody who does is a huge asset to whatever company he/she works for.

Most engineers have physical limitations. A civil engineer has gravity, tension, compression, etc. An electrical engineer has Ohm’s law, Maxwell’s laws, and other laws of physics. From what I’ve learned, Chemical Engineering is almost all about limitations, since much of what you’re doing is dealing with the elements nature has given you. Software isn’t like that. Software Engineers don’t really have physical limits beyond compute power and memory, both of which are growing exponentially.

Without the limits of other engineering fields, Software Engineering is a class of its own. Our limits are mostly our own abilities, so the discipline spends much of its energy dealing with the limitations of human programmers. There’s always the dream that someday computers will program themselves based on natural-language instructions, but that reality is still far away. Some human limitations are easy to correct: syntax errors, obvious bugs, and the like. The more insidious problem, though, is technical debt.

As a piece of software builds up over time, small mistakes accumulate. Bugs are introduced that can’t be easily reproduced. Architectural decisions make seemingly arbitrary requests nearly impossible, and the features that do get written end up hacking around those decisions. This is no big deal in the moment, but as time goes on, more and more of these little things accumulate. If ignored, they build up at such a rate that they can sink an otherwise healthy business. Thus, we software engineers must be constantly vigilant for the accumulation of technical debt, and management needs to be made aware of the issue.

I call it “technical debt” because this mass of mistakes ends up behaving much like financial debt. Like a teenager swiping a credit card without a second thought, some programmers never realize they’re creating it. After it has been created, it constantly takes time away from new features by forcing programmers to go back and correct or work around it. This diversion of resources can eat a big chunk of developer time if left ignored, much like “just paying the bills” is a struggle for people. Finally, paying technical debt off can be a huge challenge, because you must divert resources away from moving forward into what seems like a black hole. I see so many parallels between financial debt and technical debt that I would like to see a line item on financial statements for the technical portion of a software company’s debt.

Treating technical debt like financial debt gives business people a solid handle on how it works and what to do with it. If the engineering team can just provide reasonable estimates (and I think most programmers can do that), the executives of software companies will have a much better understanding of how to allocate resources. Why does it take you twice as long to get anything built this year compared to five years ago? Because we built up so much technical debt that we’re spending half our time dealing with it. Communication between business and engineering in the software world is notoriously bad, and introducing the concept of technical debt could go a long way towards facilitating that communication.