DaedTech

Stories about Software

Aug
7

By

Managing Risk via Static Analysis

Category: Language Agnostic Tags: , |

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

When software developer talk about static analysis, it’s often in the context of craft improvement.  Ask most developers in a group about static analysis tools and you’ll get a range of responses, many of which will be fueled by some degree of passion, resulting from past experience.  From here, the conversation will tend to dive into the weeds for any non-technical stakeholder that might be listening; if you’re not a programmer, you probably don’t have much of an opinion as to whether or not cyclomatic complexity of 5 is acceptable for a method.

As a result, static analysis tends to get pegged heavily as a purely a matter of shop.  The topic tends to be pretty opaque to management because developers present it to them in terms of “this will make us better and the code better.”  Management that trusts the developers will tend to agree to the purchase with a sentiment of, “okay, I’ll take your word for it.”  Management that is more skeptical says, “maybe next year if our numbers are good.”

I find this to be a shame because it’s a lost opportunity, even when management agrees.

Static analysis most certainly is a way for developers to improve their craft and their codebases.  But, in the hands of an architect or team lead that truly understands the business and works well with management, static analysis can be an excellent tool for managers, even if the use has to be a management-architect team effort.

How so?  Well, there are a lot of ways, but the one I’d like to mention today is risk management.  As the title would imply, managing risk tends to be the purview of people whose title is manager.  Sure, the developers have responsibility for this, but their primary charter is to build stuff — management exists specifically to engage in planning activities, including the crucial concern of risk management.

How does this work?  Well, I’ll show you, and I’ll do it by explaining the sort of highly technical things that static analysis could catch in highly non-technical and readable ways.  These are all going to be operational risks — static analysis can’t help you if you’re building the wrong product or badly under-staffing your projects.  But it can help you avoid landmines in your software.  If you’re a manager, allow me, for the moment, to serve as your “business-savvy architect.”

Architect

Read More

Aug
2

By

Is Your Source Control Usage Conducive to Code Review?

Category: Language Agnostic Tags: , |

Editorial Note: I originally wrote this post for the SmartBear blog.  Head over to their site and check out the original.  While you’re there, have a look around at posts by some other authors as well.

I can think back to times in my career that the source control that I was using (or not using) made me a cranky, unhappy human being.  Years and years ago, there was the time that a coworker accidentally left all of the files in the codebase checked out through Visual SourceSafe and went on vacation.  I distinctly remember enlisting a sysadmin and the two of us going into the source control server with admin credentials and hacking at settings until we could undo that and I could work.  You see, Visual SourceSafe employed a pessimistic locking strategy by which his checkout meant I couldn’t do anything with the code.

There was also the time, a few years later, when I was suffering through a project that used Rational Clear Case.  On a normal day, delivering code to the official branch or stream or whatever took half an hour.  If I had to work from home, it took all morning.

Angry guy smshing computer

And then there was the time that I was switched onto a project with no source control at all.  The C source code was stored on a production server — a production server that controlled physical machinery in the real world.  To “check things in,” you would modify the C code, turn off the physical machine, load the modified kernel modules, turn the machine on, and then revert real quick if things started blowing up.  I’m not kidding.  This was the commit/rollback strategy when I arrived (I did actually migrate this).

Tools Affect Behavior

These things make for fun war stories, but they also serve to illustrate how source control dictates behavior.  With Visual SourceSafe, we implemented some kind of out of band email protocol to remind people to check in.  With Rational Clear Case, I implemented a homegrown SVN for day to day version control and delivered/integrated only a few times per month.  With the machine server, there was extensive historical commenting in every single source file.  These tools spur you toward behaviors, and, in these cases, toward wasteful or bad behaviors.

For the examples I listed, I was steered toward useless process, steered away from continuous integration, and steered toward neurotic documentation.  But the steering can apply to almost anything, and that includes having a healthy code review process.

There have been studies conducted that demonstrate the importance of code review.  It is uniquely effective when it comes to catching defects earlier than later, and it promotes collective code ownership, thus reducing “bus factor.”  I could go on, but let’s take it as axiomatic in this post that you want to do it.

Does your source control situation make it easy for you to conduct code reviews?  Or does it discourage you, making life tough if you do them, and thus making you less likely to do them.  If it’s the latter, that’s not a good situation.

Read More

Jul
28

By

Easy to Miss Code Smells

Category: Language Agnostic Tags: | 2 Comments

Editorial Note: I originally wrote this post for the NDepend blog.  Please head over to the site and check out the original.  There’s a lot of great content over there, and, if you’re not familiar with NDepend, download a trial and try it out.

The concept of a code smell is, perhaps, one of the most evocative in our profession.  The name itself has a levity factor to it, conjuring a mental image of one’s coworkers writing code so bad that it actually emits a foul odor.  But the metaphor has a certain utility as well in the “where there’s smoke, there may be fire” sense.

In case you’re not familiar, a code smell is an observable feature of the code (the smoke) that often belies a deeper existing problem (the fire).  When you say that a code smell exists, what you’re communicating is “you may be justified here, but I’m skeptical – in my experience this is probably a design flaw.”

Smelly computer

Of course, accusing code of having a smell is only slightly less incendiary to the author than accusing code of being flat out bad.  Them’s fightin’ words, as they say.  But, for all the arguments and all of the righteous indignation that code smell accusations have generated over the years, their usefulness is undeniable.

No doubt you’ve heard of some of the most common and easiest to visualize code smells.  The God Class, Primitive Obsession, and Inappropriate Intimacy all come to mind.  These indicate, respectively a class in your code base doing way too much, a tendency to use primitive types when you should take advantage of classes, and a module or class that breaks encapsulation by knowing too many details about another.  The combination of their visual memorability and their wisdom has prodded us over the years to break things down, to create cohesive objects, and to preserve encapsulation.

I would argue, however, that there are many more code smells out there than the big, iconic ones that get a lot of attention.  I’d like today to discuss a few that I don’t think are as commonly known.  I’ll make the case for why, once you’ve mastered avoiding the well-known ones, you should watch for these as well.

Read More

Jul
17

By

How to Add Static Analysis to Your Process

Category: Language Agnostic Tags: , , |

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.

Lumbergh

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

Jun
26

By

Learning a Healthy Fear of Legacy Code

Category: Language Agnostic Tags: |

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

The life of a developer would be pretty much nothing but rainbows and unicorns if all we did was add new code to code bases. Imagine a world without maintenance programming, debugging, and scratching your head while squinting at confusing, existing code. It’d be pretty nice, right?

Unicorn with Rainbow

Sadly, we don’t live in that world. The result is that most of our efforts in software development involve a blend of new and old code. We write some new code, stuff it into some existing code, and then try to figure out how the two things will behave together in production. Consequently, both writing and reviewing code necessarily involve a kind of constant, subconscious risk management. “Hmm… should we really touch this code?”

There’s rarely a set of explicit heuristics that guide this decision; it tends to be a matter of feel. It’d be nice if there were a way to be a bit more deliberate about it.

Understanding Legacy Code

“Legacy code” is a rather nebulous term.  Even the wikipedia entry offers multiple, possible meanings.

  • Code that relates to a no-longer supported hardware or software dependency.
  • Code inherited from someone else.
  • Code that’s part of an older version of the software.
  • Code that isn’t covered by automated unit tests.

When I think about what pops into my head when someone says, “legacy code,” none of these things would surprise me.  I could imagine any or all of them being true.  But for me, legacy code really translates to, “code you’re afraid to touch.”

Read More

« Older Posts
Newer Posts »