Stories about Software


How to Add Static Analysis to Your Process

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’e there, take a look at the other posts and download a trial of NDepend, if you’re so inclined.

As a consultant, one of the more universal things that I’ve observed over the years is managerial hand-waving.  This comes in a lot with the idea of agile processes, for instance.  A middle manager with development teams reporting into him decides that he wants to realize the 50% productivity gains he read about in someone Gartner article, and so commands his direct reports or consultant partners to sprinkle a little agile magic on his team.  It’s up to people in a lower paygrade to worry about the details.

To be fair, managers shouldn’t be worrying about the details of implementations, delegating to and trusting in their teams.  The hand-waving more happens in the assumption that things will be easy.  It’s probably most common with “let’s be agile,” but it also happens with other things.  Static analysis, for example.


If you’ve landed here, it may be that you follow the blog or it may be that you’ve googled something like “how to get started with static analysis.”  Either way, you’re in luck, at least as long as you want to hear about how to work static analysis into your project.  I’m going to talk today about practical advice for adding this valuable tool to your tool chest.  So, if you’ve been meaning to do this for a while, or if some hand-waving manager staged a drive-by, saying, “we should static some analysis in teh codez,” this should help you get started.

What is Static Analysis (Briefly)?

You can read up in great detail if you want, but I’ll summarize by saying that static analysis is analysis performed on a codebase without actually executing the resultant compiled or interpreted code.  Most commonly, this involves some kind of application (e.g. NDepend) that takes your source code files as input and produces interesting output by running various analyses on the code in question.

Let’s take a dead simple example.  Maybe I write a static analysis tool that simply looks through your code for the literal string “while(true)” and, if it finds it, dumps, “ruh-roh” to the console.  I’m probably not going to have investors banging down my door, but I have, technically, written a static analysis utility.

Read More


How to De-Brilliant Your Code

Three weeks, three reader questions.  I daresay that I’m on a roll.  This week’s question asks about what I’ll refer to as “how to de-brilliant your code.”  It was a response to this post, in which I offered the idea of a distinction between maintainable code and common code.  The lead-in premise was that of supposedly “brilliant” code, which was code that was written by an ostensible genius and that no one but said genius could understand.  (My argument was/is that this is usually just bad code written by a self-important expert beginner).

The question is, as follows, verbatim.

In your opinion, what is the best approach to identify que “brilliant” ones with hard code, to later work on turn brilliant to common?

Would be code review the best? Pair programming (seniors could felt challenged…)?

Now, please forgive me if I get this wrong, but because of the use of “que” where an English speaker might say “which”, I’m going to infer that the question submitter speaks Spanish as a first language.  I believe the question is asking after the best way to identify and remediate pockets of ‘brilliant’ code.  But, because of the ambiguity of “ones” it could also be asking about identifying humans that tend to write ‘brilliant’.  Because of this, I’ll just go ahead and address both.

Einstein Thinking Public Static Void

Find the Brilliant Code

First up is identifying brilliant code, which shouldn’t be terribly hard.  You could gather a quorum of your team together and see if there are pockets of code that no one really understands, or else you could remove the anchoring bias of being in a group by having everyone assess the code independently.  In either case, a bunch of “uh, I don’t get it” probably indicates ‘brilliant’ code.  The group aspect of this also serves (probably) to prevent against an individual not understanding simply by virtue of being too much of a language novice (“what’s that ++ after the i variable,” for instance, indicates the problem is with the beholder rather than the original developer).

But, even better, ask people to take turns explaining what methods do.  If people flounder or if they disagree, then they obviously don’t get it, self-reporting notwithstanding.  And having team members not understanding pockets of code is an ipso facto problem.

An interesting side note at this point is whether this illegible code is “brilliant” or “utter spaghetti” is going to depend a lot more on knowledge of who wrote it than anything else.  “Oh, Alice wrote that — it’s probably just too sophisticated for our dull brains.  Oh, wait, you were reading the wrong commit, and it’s actually Bob’s code?  Bob’s an idiot — that’s just bad code.”

De-Brilliant The Codebase

Having identified the target code for de-brillianting, flag it somewhere for refactoring: Jira, TFS, that spreadsheet your team uses, whatever.  Just make a note and queue it as work — don’t just dive in and start mucking around in production code, unless that’s a team norm and you have heavy test coverage.  Absent these things, you’re creating risk without buy in.

Leave these things in the backlog for prioritization on the “eventually” pile, but with one caveat.  If you need to be touching that code for some other reason, employ the boy-scout rule and de-brilliant it, as long as you’re already in there.  First, though, put some characterization tests around it, so that you have a chance to know if you’re breaking anything.  Then, do what you need to and make the code easy to read; when you’re done, the same, “tell me what this does” should be easy to answer for your teammates.

De-brillianting the codebase is something that you’ll have to chip away at over the course of time.

De-Brilliant The Humans

I would include a blurb on how to find the humans, but that should be pretty straightforward — find the brilliant code and look at the commit history.  You might even be able to tell simply from behavior.  People that talk about using 4 design patterns on a feature or cramming 12 statements into a loop condition are prime candidates.

The trick isn’t in finding these folks, but in convincing them to stop it.  And that is both simple to understand and hard to do.

During my undergrad CS major many years ago, I took an intro course in C++.  At one point, we had to do a series of pretty mundane, review exercises that would be graded automatically by a program (easy things like “write a for loop”).  Not exactly the stuff dreams are made of, so some people got creative.  One kid removed literally every piece of white space from his program, and another made some kind of art with indentations.  When people are bored, they seek clever things to do, and the result is ‘brilliant’ code.

The key to de-brillianting thus lies in presenting them with the right challenge, often via constraints or restrictions of some kind.  They do it to themselves otherwise — “I’ll write this feature without using the if keyword anywhere!”

The Right Motivation

Like I said, a simple solution does not necessarily imply an easy solution.  How does one challenge others into writing the kind of straightforward code that is readable and maintainable?

Code review/pairing presents a possible solution.  Given the earlier, “can others articulate what this does” metric, the team can challenge programmer-Einstein to channel that towering intellect toward this purpose.  That may work for some, but other brilliant programmers might not consider that to be a worthwhile or interesting challenge.

In that case, automated feedback through static analysis might do the trick.  FXCop, NDepend, SonarQube, and others can be installed and configured to steer things in the general direction of readability.  Writing code that complies with all warning thresholds of such tools actually presents quite a challenge, since so much of programming is about trade-offs.  Now, a sufficiently determined clever coder could still invent ways to write hard-to-read code, but that would be a much more difficult task when he’d get slapped by the tool for chaining 20 Linq statements onto a single line or whatever.

Of course, probably the best solution is to work with the sort of people who recognize that demonstrating their cleverness takes a backseat to being a professional.  They can do that in their spare time.

If you have a question you’d like to hear my opinion on, please feel free to submit.


With Code Metrics, Trends are King

Editorial Note: I originally wrote this post for the NDepend blog.  Head over there to check out the original.  NDepend is a tool that’s absolutely essential to my IT management consulting practice, and it’s a good find for any developer and aspiring architects in particular.  Give it a look.

Here’s a scene that’s familiar to any software developer.  You sit down to work with the source code of a new team or project for the first time, pull the code from source control, build it, and then notice that there are literally thousands of compiler warnings.  You shudder a little and ask someone on the team about it, and he gives a shrug that is equal parts guilty and “whatcha gonna do?”  You shake your head and vow to get the warning situation under control.


If you’re not a software developer, what’s going on here isn’t terribly hard to understand.  The compiler is the thing that turns source code into a program, and the compiler warning is the compiler’s way of saying, “you’ve done something icky here, but not icky enough to be a show-stopping error.”  If the team’s code has thousands of compiler warnings, there’s a strong likelihood that all is not well with the code base.  But getting that figure down to zero warnings is going to be a serious effort.

As I’ve mentioned before on this blog, I consult on different kinds of software projects, many of which are legacy rescue efforts.  So sitting down to a new (to me) code base and seeing thousands of warnings is commonplace for me.  When I point the runaway warnings out to the team, the observation is generally met with apathetic resignation, and when I point it out to management, the observation is generally met with some degree of shock.  “Well, let’s get it fixed, and why is it like this?!”  (Usually, they’re not shocked by the idea that there are warts — they know that based on the software’s performance and defect counts — but by the idea that such a concrete, easily metric exists and is being ignored.)


Read More


The Most Important Code Metrics You’ve Never Heard Of

Editorial Note: I originally wrote this post for the NDepend blog.  Head on over and check out the original.  If software architecture interests you or you aspire to that title, there’s a pretty focused set of topics that will interest you.

Oh how I hope you don’t measure developer productivity by lines of code.  As Bill Gates once ably put it, “measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.”  No doubt, you have other, better reasoned metrics that you capture for visible progress and quality barometers.  Automated test coverage is popular (though be careful with that one).  Counts of defects or trends in defect reduction are another one.  And of course, in our modern, agile world, sprint velocity is ubiquitous.


But today, I’d like to venture off the beaten path a bit and take you through some metrics that might be unfamiliar to you, particularly if you’re no longer technical (or weren’t ever).  But don’t leave if that describes you — I’ll help you understand the significance of these metrics, even if you won’t necessarily understand all of the nitty-gritty details.

Perhaps the most significant factor here is that the metrics I’ll go through can be tied, relatively easily, to stakeholder value in projects.  In other words, I won’t just tell you the significance of the metrics in terms of what they say about the code.  I’ll also describe what they mean for people invested in the project’s outcome.

Read More


Using NDepend to Make You a Better Programmer

This is another post that I originally wrote for the NDepend blog. If you haven’t yet, go check out the NDepend blog and sign up for the RSS feed. It’s relatively new, but we’ll have a lot of good content there for you.

If you’re a software developer, particularly of the newly minted variety, the concept of static analysis might not seem approachable.  It sounds academic.  It sounds architect-y.  It sounds complicated.  I’ve seen this reaction from a lot of people in my career and I think that’s too bad.

If you delve into its complex depths, static analysis can be any and all of these things, but with the developers I mentor and coach, I like to introduce it as a game that makes you better at what you do.  You can use static analysis to give yourself feedback about your code that is both fast and anonymous, allowing you to improve via trial and error, rather than by soliciting feedback from people much more tenured than you and sometimes wincing as they lay into you a little.  And, perhaps best of all, you can calibrate the quality of your code with the broader development world, rather than just pleasing the guy who has hung around your company long enough to default his way into the “tech lead” role.

NDepend Rules

Take a look at some of the feedback that NDepend offers about your code.  “That method is too big” isn’t particularly intimidating, is it?  I mean, you might wonder at what you could do to compact a method, but it’s not some kind of esoteric rule written in gibberish.  You run NDepend on your code and you can see that there is some number of methods that the broader development community considers to be “too big.”

From there, you can start looking at ways to write smaller methods and to refactor some of your current ones to sneak in under the warning number.  This is the essence of gamification — you change the way you write code to get rid of the warnings.  You get better.  And it’s gratifying.

As you do this, another interesting thing starts to happen.  You start noticing that other developers continue to write large methods and when you run NDepend on their code, they light up the console with errors, whereas you do not with your code.  And so, you can have conversations with them that start with, “you know, this static analysis tool I’ve been using wants us to have smaller methods, and I’ve been working a lot on that, if you ever want a hand.”

You gain a reputation as being knowledgeable.  Before you know it, you can cite widely accepted static analysis rules and the design goals they imply.  You know these rules, and, via gamification, you have experience molding code to comply with them.  Even in cases where you might wind up overruled by the local team lead or architect, it’s no longer a simple matter of that person saying, “because I said so,” and just ending the conversation.  They have to engage with you and present cogent counter-arguments to your points.  You’re participating in important discussions in ways that you never have before.

If it sounds like I’m speaking from experience, I am.  Throughout my career, I’ve been relentless about figuring out ways to improve my craft, always trying to be a better programmer.  Early on, I was unsatisfied with a lot of arguments among developers around me that I knew boiled down to nothing more than personal preference, so I went out in search of empirical methods and broader knowledge, and that search brought me to static analysis.  I read about data and science behind particular choices in approaching software, and I schooled myself to adopt the approaches that had brought the best results.

Somewhere along that journey, I discovered NDepend and its effect on my approach to writing code was profound.  My methods shrank and became less complicated.  My architectural and design skills improved as I made it a point to avoid dependency cycles and needless coupling.  I boosted unit test coverage and learned well established language practices.  It was not long before people routinely asked me for design advice and code reviews.  And from there, it wasn’t long before I occupied actual lead and architect roles.

So, if you want to improve your craft and nudge your career along, don’t pass on static analysis, and don’t pass on NDepend.  NDepend is not just a tool for architects; it’s a tool for creating architects from the ranks of developers.  You’ll up your game, improve your craft, and even have some fun doing it.