February 2017 - NDepend

The One Thing Every Company Can Do to Reduce Technical Debt

The idea of technical debt has become ubiquitous in our industry. It started as a metaphor to help business stakeholders understand the compounding cost of shortcuts in the code. Then, from there, it grew to define perhaps the foundation of trade-offs in the tech world.

You’d find yourself hard pressed, these days, to find a software shop that has never heard of tech debt. It seems that just about everyone can talk in the abstract about dragons looming in their code, portending an eventual reckoning. “We need to do something about our tech debt,” has become the rallying cry for “we’re running before we walk.”

As with its fiscal counterpart, when all other factors equal, having less tech debt is better than having more. Technical debt creates drag on the pace of new feature deliver until someone ‘repays’ it. And so shops constantly grapple with the question, “how can we reduce our tech debt?”

I could easily write a post where I listed the 3 or 5 or 13 or whatever ways to reduce tech debt. First, I’d tell you to reduce problematic coupling. Then, I’d tell you to stop it with the global variables. You get the idea.

But today, I want to do something a bit different. I want to talk about the one thing that every company can do to reduce tech debt. I consider it to be sort of a step zero.

Continue reading The One Thing Every Company Can Do to Reduce Technical Debt

Computing Technical Debt with NDepend

For years, I have struggled to articulate technical debt to non-technical stakeholders. This struggle says something, given that technical debt makes an excellent metaphor in and of itself.

The concept explains that you incur a price for taking quality shortcuts in the code to get done quickly. But you don’t just pay for those shortcuts with more work later — you accrue interest.Save yourself an hour today with some copy pasta, and you’ll eventually pay for that decisions with many hours down the road.

So I say to interested, non-technical parties, “think of these shortcuts today as decisions upon which you pay interest down the line.” They typically squint at me a little and say, “yeah, I get it.” But I generally don’t think they get it. At least, not fully.

Lack of Concreteness

I think the reason for this tends to come from a lack of actual units. As a counterexample, think of explaining an auto loan to someone. “I’m going to loan you $30,000 to buy a car. With sales tax and interest factored in, you’ll pay me back over a 5 year period, and you’ll pay me about $36,000 in total.” Explained this way to a consumer, they get it. “Oh, I see. It’ll cost me about $6,000 if I want you to come up with that much cash on my behalf.” They can make an informed value decision.

But that falls flat for a project manager in a codebase. “Oh man, you don’t want us to squeeze this in by Friday. We’ll have to do terrible, unspeakable things in the code! We’ll create so much tech debt.”

“Uh, okay. That sounds ominous. What’s the cost?”

“What do you mean? There’s tech debt! It’ll be worse later when we fix it than if we do it correctly the first time.”

“Right, but how much worse? How much more time?”

“Well, you can’t exactly put a number to it, but much worse!”

And so and and so forth. I imagine that anyone reading can recall similar conversations from one end or the other (or maybe even both). Technical debt provides a phenomenal metaphor in the abstract. But when it comes to specifics, it tends to fizzle a bit.

Continue reading Computing Technical Debt with NDepend

Learning Programming with Hands on Projects

If you want a surefire way to make money, look for enormous disparity between demand and supply. As software developers, we understand this implicitly. When we open our inboxes in the morning, we see vacuous missives from recruiters. “Hey, dudebro, we need a JavaScript ninja-rockstar like you!”

You don’t tend to see vaguely patronizing, unflinchingly desperate requests like that unless you sit on some kind of goldmine. They approach us the way one might approach a mischevious toddler holding a winning lottery ticket. And, of course, anyone would expect that with wildly disproportionate supply and demand.

But, for us, this transcends just writing the code and oozes into learning about it. Like baseball teams playing the long game, companies would rather grow their own talent than shell out for high-priced free agents. And so learning about software might just prove more of a growth industry than writing it.

Continue reading Learning Programming with Hands on Projects

What Metrics Should the CIO See?

I’ve worked in the programming industry long enough to remember a less refined time. During this time, the CIO (or CFO, since IT used to report to the CFO in many orgs) may have counted lines of code to measure the productivity of the development team. Even then, they probably understood the folly of such an approach. But, if they lacked better measures, they might use that one.

Today, you rarely, if ever see that happen any longer. But don’t take that to mean reductionist measures have stopped. Rather, they have just evolved.

Most commonly today, I see this crop up in the form of automated unit test coverage. A CIO or high level manager becomes aware of generally quality and cadence problems with the software. She may consult with someone or read a study and conclude that a robust, automated test suite will cure what ails her. She then announces the initiative and rolls out. Then, she does the logical thing and instruments her team’s process so that she can track progress and improvement with the testing initiative.

The problem with this arises from what, specifically, the group measures and improves. She wants to improve quality and predictability, so she implements a proxy solution. She then measures people against that proxy. And, often, they improve… against that proxy.
Continue reading What Metrics Should the CIO See?