This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Technical Debt Hits The Bottom Line at EBay
Remember ten years ago, when online shopping brought “EBay” to mind? When I moved to downtown Seattle in 2001, I sold a barely-used sports car on EBay. A year later I bought a motorcycle on EBay.
Today, even the late adopters are shopping online. My wife buys grapefruit from orangesonline.com, diapers from diapers.com, baby formula from target.com, and everything else from amazon.com. When I’ve got stuff to get rid of, my first instinct is to put it on craigslist. Admirably, EBay is still in the game. But what happened to EBay’s huge lead?
According to the Wall Street Journal,
EBay’s system, which involved 25 million lines of inflexible code, soon became a liability. The company, for example, couldn’t figure out which of its hundreds of thousands of ‘iPod’ listings were for a given model or for iPod accessories. EBay’s challenges with outdated technology are common for Web pioneers, whose systems were built with custom software that is now too old and rigid to adapt to a competitive and fast-moving market.
Ouch! EBay’s technical debt is now world famous. Is EBay alone in this challenge? No. Your source code is probably worse than EBay’s, if you’re in a large, geographically-dispersed organization with a short-term “project” mentality, multi-tasked developers, command/control management habits from the manufacturing era, and little technical collaboration/mentoring. Your code is probably a toxic asset. Will you have to declare this on your company’s balance sheet to get anyone’s attention?
Even in the best circumstances, writing good code is hard. Software development strains our brain’s ability to manage complexity. If only it were as easy as rocket science. Writing code to create the appearance of progress at the moment appears to be easy. But developing a truly valuable asset requires continuous attention to technical excellence and good design. It’s just not going to happen by throwing work over the wall — or ocean — and hoping for the best. It’s not going to happen as long as developers fail to collaborate and mentor each other on a modern way to work (TDD, merciless refactoring, and continuous integration, for starters). It’s not going to happen as long as managers in the technology business run in terror from learning anything about technology.
If I were spending my own money to build a product, I’d start with a small, cross-functional team who love working with each other, and love the vision behind the product. Then I’d put them in one room, negotiate clear, tough goals, and a rigorous definition of done. At frequent intervals, such as every two weeks, we’d thoroughly inspect our progress on both the product and our process of building it. Only after getting good at that would I consider scaling it, by asking the team how they’d scale, based on what they’ve learned at that point. As Martin Fowler wrote, scaling is the last thing you should do, not the first. If the work requires intense collaboration, I’d be very cautious about introducing a planet-sized impediment by moving the work offshore.
But that’s just how I’d spend my own money, and maybe I’d do worse. EBay’s contribution to this industry is impressive. We wouldn’t know about them at all if they hadn’t brought their product to market, unlike many dot coms that produced only vapor.
Anyway, does someone want to buy a used motorcycle?
P.S. I should probably mention I don’t know anything about EBay that isn’t in the newspaper. And even if I did, do you think I’d tell you?