July 2017 - NDepend

Code Coverage Should Not Be a Management Concern

You could easily find yourself mired in programmer debates over code coverage. Here’s one, for instance. It raged on for hundreds of votes, dozens of comments, many answers, and eight years before someone put it out to pasture as “opinion-based” and closed it.

Discussion participants debated a “reasonable” percentage of code coverage. I imagine you can arrive at the right answer by taking the mean of all of the responses. (I’m just kidding.)

Some of the folks in that thread, however, declined to give a simple percentage. Instead, they gave the obligatory consultant’s response of “it depends” or, in the case of the accepted answer, a parable. I found it refreshing that not everybody picked some number between 50 and 100 and blurted it out.

But I found it interesting that certain questions went unasked. What is the goal of this code coverage? What problem does it solve? And as for the reasonability of the number, reasonable to whom?

What is Code Coverage? (Briefly)

Before going any further, I’ll quickly explain the concept of code coverage for those not familiar, without belaboring the point. Code coverage measures the percentage of code that your automated unit test suite executes when it runs.

So let’s say that you had a tiny codebase consisting of two methods with one line of code each. If your unit test suite executed one method but not the other, you would have 50% code coverage. In the real world, this becomes significantly more complicated. In order to achieve total coverage, for instance, you must traverse all paths through control flow statements, such as if conditions, switch statements, and loops.

When people debate how much code coverage to have, they aren’t debating how “correct” the code should be. Nor do they debate anything about the tests themselves, such as quantity or quality. They’re simply asking how many lines of code per one hundred your test suite should cause to execute.

You can get tools that calculate this for you. And you can also get tools that factor it into an overall code quality dashboard.

Continue reading Code Coverage Should Not Be a Management Concern

Is Your Team Wrong About Your Codebase? Prove It. Visually.

I don’t think I’ll shock anyone by pointing out that you can find plenty of disagreements among software developers.

You can see this dynamic writ large across the internet.

But you can also see it writ small among teammates in software groups. You’ve seen this before.

Individuals or small camps form around certain competing ideas, like how best to lay out the unit test suite or whether or not to use a certain design pattern.

In healthy groups, these disagreements take the form of friendly banter or good-natured ribbing. In less healthy groups, they create an us vs. them kind of dynamic and actual resentment.

I’ve experienced both flavors of this dynamic in my career. Having to make concessions about how you do things is never fun, but group work requires it.

And so you live with the give-and-take of this in healthy groups. But in an unhealthy group, frustration mounts with no benefit of positive collaboration to mitigate it.

This holds doubly true when one of the two sides has the decision-making authority or perhaps just writes a lot of the code and claims a form of squatter’s rights.

Status Quo Preservation

Division into camps can, of course, take many forms. But I think the one you see most commonly happens when you have a group of developers or architects who have laid the ground rules for the codebase and then a disparate group of relative newcomers that want to change the status quo.

I once coined a term for a certain archetype in the world of software development: the expert beginner.

Expert beginners wind up in decision-making positions by default and then refuse to be swayed in the face of mounting evidence, third party opinions, or, well, really anything. They dig in and convince themselves that they’re right about all matters relating to the codebase, and they express no interest in hearing dissenting opinions.

This commonly creates the toxic, adversarial dynamic here, and it leaves the rest of the group feeling helpless and frustrated.

Of course, this cuts the other way as well. Sometimes the longest tenured decision makers of the group earned their position for good reason and acquit themselves well in defense of their positions.

Perhaps you shouldn’t adopt every passing fad and trend that comes along. And these folks might find it tiresome to relitigate past architectural decisions ad nauseum every time a new developer hires on.

It probably doesn’t help when newbies throw around pejorative terms like “legacy code” and “the old way,” either.

Continue reading Is Your Team Wrong About Your Codebase? Prove It. Visually.

Code Quality Metrics: Separating the Signal from the Noise

Say you’re working in some software development shop and you find yourself concerned with code quality metrics. Reverse engineering your team’s path to this point isn’t terribly hard because, in all likelihood, one of two things happened.

First, it could be that the team underwhelmed someone, in some business sense — too many defects, serially missed deadlines, that sort of thing. In response to that, leadership introduced a code quality initiative. And you can’t improve on it if you can’t measure it. For that reason, you found yourself googling “cyclomatic complexity” to see why the code you just wrote suddenly throws a warning.

The second option is internal motivation. The team introduced the metrics of its own accord. In this capacity, they serve as rumble strips on the side of your metaphorical road. Doze off at the wheel a little, get a jolt, and correct course.

In either case, an odd sort of gulf emerges between the developers and the business. And I think of this gulf as inherently noisy.

Code Quality Metrics for Developers

I spend a lot of time consulting with software shops. And shops hiring consultants like me generally have code quality improvement initiatives underway. As you can imagine, I see an awful lot of code metrics.

Here are some code quality metrics that I see tracked most commonly. I don’t mean for this list to be an exhaustive one of all that I see.

Lines of code. (This is an interesting one because, in aggregate, it’s often used to track progress. But normalized over smaller granularities, like types and methods, people correlate it negatively with code quality — “that method is too big.”)
Cyclomatic complexity: the number of execution paths that exist through a given unit of code. Less is more.
Unit test coverage: the percentage of paths through your code executed by your unit test suite. More is more.
Static analysis tool/lint tool violations count: run a tool that provides automated code checks and then count the number of issues.

As software developers, we can easily understand these concepts and internalize them. But to explain to the business why these matter requires either a good bit of effort or a “just trust us.” After all, the business won’t understand these concepts as more than vague generalities. There’s more testing coverage, or something…that sounds good, right?

These metrics can then have noise in them, meaning that how important they are for business outcomes becomes unclear.

Continue reading Code Quality Metrics: Separating the Signal from the Noise

C# Version History: Exploring the Language History from Past to Present

C# Version History: Examining the Language Past and Present

I still remember my first look at C# in the early 2000s. Microsoft had released the first major version of the language. I recall thinking that it was Java, except that Microsoft made it, called it something else, and put it into Visual Studio. And I wasn’t alone in this sentiment. In an old interview, Java inventor James Gosling called it an imitation. “It’s sort of Java with reliability, productivity, and security deleted,” he said. Ouch.

A lot changes in 15 years or so. I doubt anyone would offer a similar assessment today. In that time, Java has released four major language versions, while C# has released six. The languages have charted divergent courses, and C# has seen a great deal of innovation. Today, I’d like to take a look back on the history of C# and highlight some of those key points.

What did the language look like in its earliest incarnations? And how has it evolved in the years since?

Continue reading C# Version History: Examining the Language Past and Present