How DNSimple Handles Technical Debt

DNSimple was founded in 2010, and our offering has grown and changed a lot over those 15 years. We've evolved in complexity along with our customer needs and had team members come and go throughout the years. It's like a living thing. It also means we have a 15-year-old codebase and all the technical debt that entails.

Growing our product comes with more technical debt. We inherited challenges from years when technical debt went uncharted, plus the new debt we introduce whenever we ship new features. We recently talked about what technical debt is, so in this post, we'll dive a bit deeper.

How does DNSimple manage technical debt and still have time to ship new features simultaneously? We treat it as a strategic investment that enables faster value delivery while providing long-term maintainability.

How DNSimple handles technical debt

There are myriad inherited past decisions in a 15-year-old codebase. We could think about this as multiple loans and options in motion already, but we're also shipping new features, involving new tradeoffs to hit deadlines and get early feedback from our customers.

So, what's DNSimple's strategy around technical debt right now? Great question.

We work through these changes in the code base, and technical debt adds costs to those changes. It adds hidden risks, because technical debt, especially when it's uncharted, can easily pop up in a project to derail estimations or planned work. And it limits our choices when it comes to vendor lock in. Well-designed software should be able to swap parts easily, and badly designed code is harder to replace — or even remove.

Our team can't stop everything, pay technical debt, then resume everything. It needs to be compatible with how we work and keep a balance between what's new and what's maintenance. We work to identify and document the existing technical debt whenever a project goes out. We try to figure out what technical debt is left to be paid, and document it. We also get feedback from stakeholders about the current state of product roadmaps and planning.

Another key is working in small, iterative improvements. Our structure includes six weeks of building, two weeks of cooldown, and two weeks of cycle break, and anything we want to make regarding technical debt needs to fit into this structure. This ensures there's a high chance for us to actually do something about the technical debt — without disrupting product development.

Because of that, technical debt is an investment. We align it with roadmaps, emphasize small delivery cycles, and make deliberate choices about when and where to invest in paying it down. This enables us to release new features or improvements earlier and more often. We can also produce mockups of other things we want to explore much faster.

A beneficial investment

Proactively handling technical debt benefits everyone working on DNSimple's app:

On the product side, it impacts strategic planning. Parts of the software that are well-built can be planned more easily than parts that require preparation before a project can be tackled. It also supports the 'explore vs expand vs extract' mindset by addressing design decisions differently based on the context of specific goals.

For sales and marketing, deferring on code design means being able to deliver key features earlier, making the product more cutting edge and marketable.

And in terms of engineering, technical debt directly impacts the economies of scale associated with software development. Paying off technical debt helps keep costs at bay, which puts us in a better position to ensure the product's viability for the next 15 years.

A real example of this is email forward management. We wanted to improve our error management with our upstream provider, and we also knew that we would like to add other providers to enrich our offering eventually. Therefore, while working on the error management issue, we paid some of the technical debt around that component to decouple it from concerns specific to our current single provider. Now, planning the work to introduce a new provider it's much easier because it will take less time and it requires less prior knowledge.

Technical debt is a valuable investment for everyone in a company and, when handled well, can benefit your overall offering and enhance your customer experience.

Your strategy for handling technical debt will depend on your company's needs. Open communication is key — you need to understand what customers want, align with other teams, plan strategically to implement new offerings, and work in defined delivery cycles, all while balancing the costs of changes to your codebase. If you approach it as an investment, you'll be able to build cutting edge, marketable software, and maintain your codebase in preparation for future opportunities.

A deferred investment

The DNSimple team thinks of technical debt as a deferred investment in design, because it's a strategic tool we have. It's not a mistake, it's not an error, and it's not a result of poor coding practices. It's about postponing design choices, and delivering more value, earlier to our customers.

We also acknowledge and track the costs that will grow over time if we don't pay this technical debt. It requires active management and planning, but it's crucial for meeting needs quickly and setting ourselves up for success with streamlined, cutting edge technology.

You can read more in our first post What is Technical Debt?, or get advice straight from our CEO on Paying Back Technical Debt.

If you have more questions, or want to talk about how DNSimple can help you achieve the easiest domain management possible, drop us a line — we'd love to help.

Not using DNSimple yet? Give us a try free for 30 days to explore our integrations and multiple features that ensure your domain management is as simple and secure as possible.

Share on Twitter and Facebook

Guillermo Gutiérrez

Father, husband, software developer, amateur cook and baker, coffee enthusiast, maker aficionado, and Oxford comma fan.