Stories about Software


How Code Review Saves You Time

Editorial note: I originally wrote this post for the SmartBear blog.  Check out the original here, at their site.  While you’re there, take a look around at their offering.

Physical labor is one of the most strangely enduring mental models for knowledge work.  Directors and managers of software development the world over reactively employ it when nudged out of their comfort zones, for instance.  “What do you mean ‘pair programming’ — we’ll get half of the work done for the same payout in salary!”  And that’d be a reasonable argument if the value of software were measured in “characters typed per minute.”


Most of the skepticism of activities like unit testing and code review originates from this same “knowledge work as labor” confusion.  The core value of software resides in the verbatim contents of the source code files, so stuffing all of the features in them ahead of the deadline is critical.  Testing and reviewing are “nice-to-haves”, time and budget permitting.

The classic response from people arguing for these practices is thus one of worth.  It goes something like this: “sure, you can cut those activities, but your quality will dip and there will be more escaped defects.”  In other words, these ‘extra’ activities pay for themselves by making your outfit look less amateurish.  That argument often works, but not always.  Some decision-makers, backs truly to the wall, say “I don’t care about quality — my job depends on shipping on June 19th, and we’re GOING to ship on June 19th, whether it’s a finished product or whether it’s a bag of broken kazoos and cyanide with a bow on it.”

I’d like to take a different tack today and fight a time argument with time arguments.  Instead of “sure, code reviews take extra time but they’re worth it,” I’d like to explore ways that they actually save time.  Whether they save more time than take is going to vary widely by situation, so please don’t mistake my intent; I’m not looking to argue that they’ll save you net time, but rather that they are not exclusively an investment of time.

Read More


How to Actually Reduce Software Defects

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  Have a look around while you’re there and see what some of the other authors have written.

As an IT management consultant, probably the most frequent question I hear is some variant of “how can we get our defect count down?” Developers may want this as a matter of professional pride, but it’s the managers and project managers that truly burn to improve on this metric. Our software does thousands of undesirable things in production, and we’d like to get that down to hundreds.


Almost invariably, they’re looking for a percentage reduction, presumably because there is some sort of performance incentive based on the defect count metric. And so they want strategies for reducing defects by some percentage, in the same way that the president of the United States might challenge his cabinet to trim 2% of the unemployment percentage in the coming years. The trouble is, though, that this attitude toward defects is actually part of the problem.

The Right Attitude toward Defects

The president sets a goal of reducing unemployment, but not of eliminating it. Why is that? Well, because having nobody in the country unemployed is simply impossible outside of a planned economy – people will quit and take time off between jobs or get laid off and have to spend time searching for new ones. Some unemployment is inevitable.

Management, particularly in traditional, ‘waterfall’ shops, tends to view defects in the same light. We clearly can’t avoid defects, but if we worked really hard, we could reduce them by half. This attitude is a core part of the problem.

It’s often met with initial skepticism, but what I tell these clients is that they should shoot for having no escaped defects (defects that make it to production, as opposed to ones that are caught by the team during testing). In other words, don’t shoot for a 20% or 50% reduction – shoot for not having defects.

It’s not that shooting for 100% will stretch teams further than shooting for 20% or 50%. There’s no psychological gimmickry to it. Instead, it’s about ceasing to view defects as “just part of writing software.” Defects are not inevitable, and coming to view them as preventable mistakes rather than facts of life is important because it leads to a reaction of “oh, wow, a defect – that’s bad, let’s figure out how that happened and fix it” instead of a reaction of “yeah, defects, what are you gonna do?”

When teams realize and accept this, they turn an important corner on the road to defect reduction.

Read More


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


Solve Small Problems

Editorial Note: I originally wrote this post for the Infragistics blog.  Go check out the original at their site.  While you’re there, go check out their developer tools and controls.

It’s fun to think of great moments in the history of science, particularly the ones that have a memorable anecdote attached to them.  In the 3rd century BC, a naked Archimedes ran down a city street, screaming Eureka, because he had discovered, in a flash, how to measure the volume of irregular solids.  In the 1600s, a fateful apple bonks Issac Newton on the head, causing him to spit out the Theory of Gravity.  In the early 1900s, another physicist is sitting around, contemplating the universe, when out pops E=MC^2.

Newton Getting Bonked with an Apple

These stories all share two common threads: they’re extremely compelling and entirely apocryphal.  As such, they make for great Disney movies, but not such great documentaries.  Point being, we as humans like stories of “eureka moments” and lightning bolt inspiration much better than tales of preparation, steady work, and getting it right on attempt number 2,944, following 2,943 failed attempts.

But it goes beyond just appreciating the former type of story.  We actually manufacture them.  Perhaps the most famous sort of example was Steve Jobs’ legendarily coy, “oh yeah, there’s one more thing” that preceded the unveiling of some new product or service.  Jobs and Apple were masters of “rabbit from the hat” marketing where they’d reveal some product kept heretofore under wraps as though it were a state secret.  All that is done to create the magic of the grand reveal — the illusion that a solution to some problem just *poof* appeared out of thin air.

Unrealistic Expectations

With all of this cultural momentum behind the idea, it’s easy for us to internalize it.  It’s easy for us to look at these folk stories of scientific and product advancement and to assume that not having ideas or pieces of software fall from us, fully formed and intact, constitutes failure.  What’s wrong with us?  Why can’t we just write that endpoint in one shot, taking into account security, proper API design, backward compatibility, etc?  We’re professionals, right?  How can we be failing at this?

You might think that the worst outcome here is the ‘failure’ and the surrounding feelings of insecurity.  But I would argue that this isn’t the case at all.  Just as the popular stories of those historical scientists are not realistic, and just as Apple didn’t wave a magic wand and wink an iPod Nano into existence, no programmer thinks everything through, codes it up, and gets it all right and bulletproof from the beginning.  It simply doesn’t happen.

Read More


Modern Software Development at Its Core

I spend a lot of time in hotels, so it’s pretty unremarkable that I would spend the first week of 2016 on the 6th floor of some Marriott.  I unpacked and put my things in their usual places.  I make coffee in the room’s coffee-maker the same way each morning.  And I hit the hotel gym each day for a 3-4 mile jog between end of business and going for dinner.  In terms of my routine, the first week in January is like every other week of the year that I’m on the road.

What’s not the same as every other week of the year is what awaits me when I arrive at the hotel gym.  In December, it’s a roomful of softly humming treadmills and a TV firing out staccato bursts of salacious, 24 hour news at a mercifully low volume — the exercise room equivalent of a ghost town.  This week, it’s full of newly New Years-resolved exercisers, armed with old walkmans, weird headbands, and pitted out T-shirts that, until this day, were reserved for painting the house.

A Pitched Battle with a Treadmill

One such man came in at the same time as me, and took the treadmill next to mine.  I punched in my workout settings and started out at my usual 6 miles per hour, while the man next to me fiddled with his treadmill for a few minutes.  Once he got started, he peered at me every few seconds, as if I were taking a midterm via treadmill and he wanted to copy my answers.  He worked himself up to a speed similar to mine, and everything seemed to be in rhythm for 2-3 minutes, until his breathing became extremely labored and ragged.

Naturally, at this point, rather than pausing the treadmill or slowing the speed, he lifted himself off of the belt like a gymnast performing on the parallel bars.  Once this became untenable, he set one foot down on either side of the belt, tottered awkwardly a bit, and then jumped off the treadmill.  I assumed he was done, wanting to live to fight another day, but a few minutes later, he returned with a towel and leapt back onto the treadmill, using his arms to resume his former pace.  Luckily for him, he did then figure out how to adjust his speed, allowing him to alternate between sprinting and walking until he decided he’d had enough.


A lot of gym regulars, as I understand it, find New Years resolvers to be annoying.  I understand this sentiment if you take them as an entire group, seriously clogging up the gym for the first 3-4 weeks of the year.  But it’s hard to fault any individual for wanting to engage in some self improvement and overcoming inertia (and annoyed veterans) to get started.  In fact, it’s downright laudable.

Read More