Stories about Software


The Biggest Mistake Static Analysis Prevents

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  Take a look at NDepend while you’re there; if static analysis interests you in the .NET space, it’s a must-try.

As I’ve probably mentioned before, many of my clients pay me to come do assessments of their codebases, application portfolios and software practice.  And, as you can no doubt imagine, some of my sturdiest, trustiest tools in the tool chest for this work are various forms of static analysis.

Sometimes I go to client sites, by plane, train or automobile (okay, never by train).  Sometimes I just remote in.  Sometimes I do fancy write-ups.  Sometimes, I present my findings with spiffy slide decks.  And sometimes, I simply deliver a verbal report without fanfare.  The particulars vary, but what never varies is why I’m there.

Here’s a hint: I’m never there because the client wants to pay my rate to brag about how everything is great with their software.

Smelly computer

Where Does It All Go Wrong?

Given what I’m describing here, one might conclude that I’m some sort of code snob and that I am, at the very least, heavily judging everyone’s code.  And, while I’ll admit that every now and then I think, “the Daily WTF would love this,” mostly I’m not judging at all – just cataloging.  After all, I wasn’t sitting with you during the pre-release death march, nor was I the one thinking, “someone is literally screaming at me, so global variable it is.”

I earnestly tell developers at client sites that I don’t know that I’d have done a lot better walking a mile in their shoes.  What I do know is that I’d have, in my head, a clearer map from “global variable today” to “massive pain tomorrow” and be better able to articulate it to management.  But, on the whole, I’m like a home inspector checking out a home that was rented and subsequently trashed by a rock band; I’m writing up an assessment of the damage and not tsking their lifestyle.

But for my clients, I’m asked to do more than inspect and catalog – I also have to do root cause analysis and offer suggestions.  So, “maybe pass a house rule limiting renters to a single bottle of whiskey per night,” to return to the inspection metaphor.  And cataloging all of these has led me to be a veritable human encyclopedia of preventable software development mistakes.

I was contemplating some of these mistakes recently and asking myself, “which was the biggest one” and “which would have been the most preventable with even simple analysis in place?”  It was interesting to realize, after a while, that the clear answer was not at all what you’d expect.

Read More


What a Software Audit Means for You

Editorial Note: I originally wrote this post for the SmartBear blog.  Check out the original, here, at their site.  While you’re there, have a look around at some of the other authors’ posts.

“We’re being audited.”

Now there’s a sentence to strike fear into anyone’s heart. The most famous and iconic example of an audit is the dreaded IRS audit. This audit is the IRS’s way of saying, “you did something wrong during the course of an extremely byzantine process we force on you, and now we’re going to make your life miserable by going through every inch of your life with a fine-toothed comb.” Or at least, that is the reputation.


Now, while I’m not here to defend the US tax code nor bureaucracy in general, I will say that this is not exactly what the IRS is saying. Rather, they’re saying, “we’ve noticed inconsistencies between what you’ve reported and what we’ve observed elsewhere, and we are going to investigate further.” And, while this investigation does, in fact, mean a lot of unpleasantness for you, that is not the purpose. An audit, per its dictionary definition, is “a methodical examination and review.”

Audits at Your Place of Business

Considered this way, the word loses some of its onerousness, since it is not deliberately punitive. But it’s still not exactly a cause to throw a party – it means that someone is about to come take a very close look at something you’ve done, with exacting rules and detailed expectations. You’re about to be under a microscope.

Having established that an audit is strict and not punitive, what are the implications for you, as a software developer? What does it mean for you code/software to be audited? If your boss or a colleague utters those three fateful words, “we’re being audited,” what does this mean for your organization and for you?

Well, I’m a consultant, so you can probably predict my answer: “it depends.” “We’re being audited” is informative, but it’s not quite enough information. There are, after all, different kinds of audits, conducted for different purposes. Let’s consider a few of them.

Read More


How to Get Developers to Adopt a Coding Standard

Editorial Note: I originally wrote this post for the NDepend blog. Head over to their site and check out the original, here.  While you’re there, have a look around at the other posts; if you enjoy static analysis, you’ll enjoy what’s there.

If you’re a manager, there’s a decent chance that the subject of coding standards makes you want to bang your head against a wall repeatedly.  If you’re a developer, you can probably understand why this is true of your manager, if you think about it.

The group coding standard has the following properties.

  • It’s extremely technical and granular.
  • Developers tend to squabble about it.
  • If it produces any business value, it does so obliquely and theoretically, from management’s perspective.

Thus, if I’m a manager, there’s this inscrutable document out there that causes my team to argue, and whose existence I must take on faith to be a good thing.  As you can see, it doesn’t start out on my good side.

Does It Matter?

There are all manner of opinions and arguments to be found on the internet as to why a coding standard matters (or doesn’t).  I’ve wrote about the subject myself from time to time.  So, without belaboring the point, I’ll make the quick business case for it.

The purpose of a coding standard, at its core, is twofold:

  1. It promotes maintainability by making all code look similar and familiar to all developers.
  2. It standardizes approaches that promote correct code (and avoid incorrect code).

Thus, on the whole, the coding standard makes the total cost of ownership of the codebase decrease by some amount ranging between 0 and “indeterminate.”  As an outside party, you simply have to take on faith that there is an ROI and that the amount of time wasted in arguments, complaining, and compliance is offset by the reduced troubleshooting and onboarding times.

And, in my experience, it generally is.  Notwithstanding pouting and bickering that happens early in the project and makes life unpleasant, it’s better to have these things than not to have them.  The key, then, becomes minimizing the cost of having the standard.  And you do this by securing compliance with the least amount of heartburn for all involved.

So how do you do that?  How do you convince the developers to buy in with a minimum of resistance and friction?


Read More


The Billing Maturity Model

Editorial Note: I just want to mention that I realize I’ve done a disproportionate amount of cross-posting lately.  Perhaps no one notices or cares; these posts generally seem to be pretty popular.  But in case you were wondering why I’m doing that, instead of DaedTech-specific posts or answering reader questions, it’s because I’m trying to focus most of my non-paid writing on Developer Hegemony.  I’m getting into the homestretch with it. Once I finish the draft, you’ll probably see a higher ratio of DaedTech-specific posts.

Last week, I wrote a post about my experience with software consulting.  It generated some buzz and discussion, and I received a good bit of feedback from regular readers that they’d like to see more of these posts about the consulting game.  Today I’m going to oblige.

In that post, I talked obliquely about wanting to get away from hourly billing models.  The main thrust of the post was about two realizations that have been more central to my happiness (writing code at an hourly rate is a career-limiting activity and engagements of indefinite length create pseudo-employment).  As a result, the general theme of alternatives to hourly billing took a backseat.

The Challenge of Doing Something Other Than Hourly Billing

I have strong feelings about this topic, but I also view it as a larger topic and a larger hill to climb.  After all, I can keep myself happy by simply avoiding hourly coding (in favor of strategy consulting, training, and the like) and only agreeing to engagements once success criteria have been established.  Client don’t push back against these considerations.

But things tend to get more interesting when you propose arrangements other than hourly billing.  For many clients, this is befuddling and unheard of.  You might as well propose that they also start working from 8 PM to 4 AM.  Thus moving away from hourly billing requires more strategy and finagling.

In this post, I’m not going to delve into that strategy.  I mention the difficulty of moving away from hourly billing only as an explanation for why I haven’t yet eliminated it from my life altogether, the way that I have with hourly coding and open-ended engagements.

Instead, I will talk today about alternatives to hourly billing.  Some of these I’ve explored, and some of these I’m seeking to explore.  But I believe all of these billing models fall along a continuum of what I think of as a maturity model of billing arrangements.

It might surprise you to learn what I believe the differentiator is along this axis.  It’s not profitability nor advantage for the consultant.  It has nothing to do with status or business/management fads.  Rather, I evaluate these models in terms of the amount of partnership that takes place between consultant and client.


Read More


Static Analysis for Small Business

Editorial note: I originally wrote this post for the NDepend blog.  Check out the original, here, at their site.  While you’re there, download a trial of NDepend and give it a spin.  It’s one of the most important tools in my software consultant’s tool chest.

I was asked recently, kind of off the cuff, whether I thought that static analysis made sense for small business.  I must admit that the first response that popped into my head was a snarky one: “no, you can only reason about your code once you hit 1,000 employees.”  But I understood that the meat of the question wasn’t whether analysis should be performed but whether it was worth an investment, in terms of process and effort, but particularly in terms of tooling cost.

And, since that is a perfectly reasonable question, I bit my tongue against the snark.  I gave a short answer more or less of “yes,” but it got me thinking in longer form.  And today’s post is the result of that thinking.

I’d like to take you through some differences between small and large organizations.  And in looking at those differences, I will make the perhaps counter-intuitive case that small companies/groups actually stand to benefit more from an investment in static analysis tools and incorporation of the same into their software development processes.

Read More