October 2016 - NDepend

Making Devs, Architects, and Managers Happy with the Static Analysis Tool

Organizations come to possess a static analysis tool in a variety of ways. In some cases, management decides on some kind of quality initiative and buys the tool to make it so. Or, perhaps some enterprising developers sold management on the tool and now, here it is. Maybe it came out from the architecture group’s budget.

But however the tool arrives, it will surprise people. In fact, it will probably surprise most people. And surprises in the corporate context can easily go over like a lead balloon. So the question becomes, “how do we make sure everyone feels happy with the new tool?”

A Question of Motivation

Before we can discuss what makes people happy, we need to look first at what motivates them. Not all folks in the org will share motivation — these will generally vary by role. The specific case of static analysis presents no exception to this general rule.

When it comes to static analysis, management has the simplest motivation. Managers lack the development team’s insights into the codebase. Instead, they perceive it only in terms of qualitative outcomes and lagging indicators. Static analysis offers them a unique opportunity to see leading indicators and plan for issues around code quality.

Architects tend to view static analysis tools as empowering for them, once they get over any initial discomfort. Frequently, they define patterns and practices for teams, and static analysis makes these much easier to enforce. Of course, the tool might also threaten the architects, should its guidance be at odds with their historical proclamations about developer practice.

For developers, complexity around motivation grows. They may share the architects’ feelings of threat, should the tool disagree with historical practice. But they may also feel empowered or vindicated, should it give them a voice for a minority opinion. The tool may also make them feel micromanaged if used to judge them, or empowered if it affords them the opportunity to learn.

Continue reading Making Devs, Architects, and Managers Happy with the Static Analysis Tool

Static Analysis for the Build Machine?

I remember my earliest experiences with static analysis. Probably a decade ago, I started to read about it during grad school and poke around with it at work. Immediately, I knew I had discovered a powerful advantage for programmers. These tools automated knowledge.

While I felt happy to share the knowledge with coworkers, their lack of interest didn’t disappoint me. After all, it felt as though I had some sort of trade secret. If those around me chose not to take advantage, I would shine by comparison. (I have since, I’d like to think, matured a bit.) Static analysis became my private competitive advantage — Sabermetrics for programmers.

So as you can imagine, running it on the build machine would not have occurred to me. And that assumes a sophisticated enough setup that doing so made sense (not really the case back then). Static analysis was my ace in the hole for writing good code — a personal choice and technique.

Fast forward a decade. I have now grown up, worked with many more teams, and played many more roles. And, of course, the technological landscape has changed. All of that combined to cause a complete reversal of my opinion. Static analysis and its advantages matter far too much not to use it on the build machine. Today, I’d like to expand on that a bit.
Continue reading Static Analysis for the Build Machine?

static analysis continuous testing relationship

The Relationship between Static Analysis and Continuous Testing

As an adult, I have learned that I have an introvert type personality. I do alright socially, don’t mind public speaking, and do not (I don’t think) present as an awkward person. So, learning about this characterization surprised me somewhat, but only until I fully understood.

I won’t delve into the finer points of human psychology here, but suffice it to say that introverts prefer to process and grok questions before responding. This describes me to a tee. However, working as a consultant and giving frequent advice clashes with this and has forced me to develop somewhat of a knack for answering extemporaneously. Still, you might ask me just the right question to cause me to cock my head, blink at you, and frown.

I received just such a question the other day. The question, more or less, was, “if we have continuous testing, do we really need static analysis?” And, just like that, I was stumped. This didn’t square, and I wanted time to think on that. Luckily, I’ve had a bit of time. (This is why I love blogging.) Continue reading The Relationship between Static Analysis and Continuous Testing

How to Perform Effective Team Code Reviews

I’ve heard people say (paraphrased) that teams succeed uniformly, but fail each in its own unique way. While I might argue the veracity of this statement, it evokes an interesting image. Many roads, lined with many decisions, lead to many different sorts of failures. Team code reviews present no exception. Teams can fail at code review in myriad, unique ways. And, on top of that, many paths to broader failure can involve poor code reviews (doubtless among other things).

How can I assign such importance to the code review? After all, many would consider this an ancillary team activity and one with only upside. Done poorly, code review catches no defects. Done well, it catches some defects. Right? Continue reading How to Perform Effective Team Code Reviews