A Tale of Two Teams
Company A sells customised teddy bears. When they first started up, the codebase was a mess. Different parts of the system were written by different developers with hardly any communication. Change was slow, unpredictable and the finished product was often broken if indeed it functioned at all.
After A found its business model, it hired new developers. Key services like teddy bear size customization, assembly and templating were refactored out into their own services. They integrated with other web services that allowed you to for example, print your Flickr photos on your custom teddy bear.
Years later, after a lot of time and money spent on new features, integrations and refactoring, a huge social network with hundreds of millions of users offer to broker a deal that would result in a great deal of publicity and new sales for Company A. The technical integration is complete in a matter of months, but business negotiations delay the project somewhat. The result is a resounding success.
Company B sells a suite of business process automation tools for enterprise clients. Over the years it made deals with various large corporations and built custom solutions for each. B eventually decided to abstract its software products so that they might be sold to more than one customer, but each product in itself was its own codebase.
Over the years more and more products accumulated, some for all clients, some for clients in a given country, and still others custom-built for a particular client. There was no automated way for a client to pick and choose between products; after a deal was made an operations team would spend months doing technical setup for each and every new customer.
Everyone inside Company B can see the value of integrating products in such a way that clients can pick and choose which products to use on their own, so a new project is started to do just that. Having some sort of sales portal sitting in front of their products would allow for self-service clients, and initial research shows immense potential for new revenue.
The project is estimated to take months, but goes over schedule and years later is still a work in progress, sidelined while newer client integrations take precedence. Why? What's the difference between A and B, and how is it that their results were so different in the face of opportunity?
Paying Down Technical Debt
A disorganized project with lots of duplicate code, no separation of concerns, little accurate documentation and few automated tests is said to have accrued a lot of technical debt. Projects with a lot of technical debt are difficult to build new features for and prone to bugs that are difficult to diagnose and fix.
The standard model for developing web applications in an "agile" way is to quickly build a first version with little thought towards any accrued technical debt, and to then go back at a later stage to "refactor" code or architecture. While some more enlightened companies allow technical staff time dedicated to refactoring, its often squeezed in between feature requests and bug reports.
As a profession we're not very good at selling the idea of refactoring. To say simply that it helps us "pay down technical debt", even after explaining in detail what technical debt is sells the benefits short.
As long as we phrase the activity as fixing a wrong, it will be difficult to bring other people in a given company onboard with the practice of refactoring. We know intrinsically what the benefits are, especially in an organisation where business requirements change quickly.
Building Technical Assets
Let's take a sample of wikipedias definition of technical debt:
- Lack of building loosely coupled components
- Lack of test suite
- Lack of documentation
Notice that each of these fits the pattern of "Lack of X".
What I propose is that instead of considering each of these item as a lack of something we should have, that instead they're things that we should aim towards together. Going after Technical assets as opposed to paying down technical debt.
Selling on benefits is a much more effective way to argue for time to do something. You build loosely coupled components and architecture so that when Facebook come along with a life-changing opportunity, your application is ready to integrate. You have a test suite so that you can continuously crank out features without breaking old ones. You have documentation so that you can get new developers delivering software from day one.
There's no need to label the lack of these things as Technical Debt. Instead, we'd all be better served by making these goals in and of themselves, and selling them for their benefits to the rest of your organisation. In the 21st century, concerns like these have a direct impact on a businesses ability to capitalize on opportunity, but it's up to us as technical professionals to make the case.