Recently I’ve been gratified to read a couple of well-argued, nuanced assessments of the risks and advantages of the strategic accrual of technical debt: Joe Xavier’s How to Make Debt Pay, on TechCrunch, and Harry Roberts’s We Need to Talk About Technical Debt, over at the seasonally themed 24 Ways blog. These articles provide concrete examples of the utility of debt, making it clear that the issue of technical debt isn’t nearly as simple as “debt = bad”. (Although bad code, which isn’t the same thing as technical debt, does indeed simply “equal bad”.)
I’d like to extend the financial analogy a bit and talk in terms of technical credit. I’m certainly not the first one to explore this concept; senior Red Hat developer Jeff Darcy has written on the subject, memorably describing technical credit as “a library of solved problems”. He goes on to describe “prototypes, code snippets, or designs in various stages of completion” which may be “pressed into immediate service” when the need arises. In the context of Harry’s scenario concerning a CSS theming system, an example of Jeff’s conception of technical credit might be a couple of specced-out and half-built ideas for such a system. These code snippets are “in the bank”, as it were, and so are ready to be developed into a fully-built feature when the customer hands down their ultimatum.
At Axure, we’ll sometimes (but certainly not always) try to build technical credit into a project. Our guidelines are somewhat loose, but we’ll probably do it when:
- We have “a pretty good sense” we’ll want to offer a particular feature later on, but not right now.
- We think we have a good plan for how it can be implemented.
- We have the time right now to implement it.
The Axure variety of technical credit is perhaps a little different from Jeff Darcy’s, at least in terms of degree. Instead of stockpiling code that might allow for a feature to be developed more quickly and responsibly, we like to build out a feature to a close-to-1.0 state and then put it right into the production release, where it’s generally hidden in plain sight. So to return again to Harry Roberts’s example of a theming system, we might go ahead and build such a system just to run a product’s default theme if the above criteria are met (we have the time and so on). We’ll then hold off on exposing it via the UI until we’re sure that it’s fully baked and aligns with our broader product goals
Historically, we’ve been particularly keen to work this way when developing Axure Share, our prototype hosting service. We made the decision back in 2012 to completely rebuild it, creating a full-featured product out of what had been an “Axure Labs” experiment. (Picture no logging in, no reusing prototype IDs, 30-day prototype lifespan.) We weren’t sure at the time exactly what Axure Share would later turn into, though we had some ideas. Could it be used to host team projects? Could it become a hub for widget libraries? What roles and permissions might customers want? As we rebuilt, we put in the extra time and coding effort so that these types of enhancements could be easily integrated down the road.
Years later, in 2016, these earlier decisions made it possible for us to offer Axure Share Enterprise and Axure Share hosting for team projects and widget libraries as part of the Axure RP 8 release cycle. If we’d stuck with the original architecture of Axure Share, it would have been much more effort-intensive to build these products and features alongside the rest of the Axure RP 8 update. The additions to Axure Share probably wouldn’t have made the cut for version 8, and we’d quite possibly still be without them today.
The “plugins” feature of Axure Share is another example of technical credit. The plugins feature, along with pretty URLs and redirects, were originally built into Axure Share because we needed them for ourselves. (We needed them in order to build and host our corporate site as an Axure RP project, which continues to be how we maintain the site to this day.)
But we had the idea that customers might someday be interested in these capabilities too, and so instead of implementing one-off solutions, we built a framework. The UI wasn’t very polished, and there were bugs to be sure, but it worked—and in the long run it required less of our time and effort than it would to have implemented the one-off solutions for our own project and then later gone back and built a set of tools to allow others to accomplish the same things.
Of course, our efforts at building for the benefit of our future selves don’t always work out as tidily as the above examples. (As Branch the Troll so eloquently put it, “the world isn’t all cupcakes and rainbows.”) But we continue to look for opportunities to do it because we think it works out for us, and our customers, on balance.
And please don’t take all this to mean that we don’t accrue our fair share of debt as well; we certainly do. But that’s a story for another day and another article.