Stories about Software


A Manager’s Guide to Legacy Code

Editorial Note: I originally wrote this post for the NDepend blog.  Go check out the original here, at their site.  If you like posts about static analysis, code quality, and architecture, head on over and check it out.

If you have a sadistic streak and manage a team of software developers, it’s probably high entertainment to dredge up some old, dusty piece of software and then to task them with maintaining it.  If, on the other hand, you’re a normal human being and you’re asking this because it’s necessary for your business, you brace yourself.  After all, this is legacy software, and the reaction of the team is likely to be quite predictable.

Alright, let’s take a look at this thing.  Oh, man, look at that right there.  A global variable.  And — oh my god — there are dozens of these things.  Who even wrote this?  And, look at this over here.  That’s the kind of idiotic, backward code that we used to have to write 20 years and 6 language versions ago when this code was current.  But even when it was current, this code was horrible.  This was obviously written by a trained ape.

When you’re a developer, the only thing worse and more contemptible than the uninformed code you wrote years ago, is the code that someone else wrote years ago.  Not only is it alien to you in makeup and reasoning, this legacy code also features patterns that have gone out of date or even been forgotten.


But lest you, as a manager, assume that this is simply a matter of developers being prima donnas, consider that an encounter with legacy code bother developers precisely because it renders them less effective.  They’re professionals, wanting to do good work, and the lead balloon you’ve dropped in their lap is an impediment to that.

Read More


Software Rewrite: The Chase

Editorial note: I’ve been on the road for the last week with a pretty hectic schedule — a mix of business and personal.  Luckily, I have a lot of cross posts stored that were fairly popular.  I originally wrote this one for the NDepend blog.  Go check out the original and stick around to look at other posts while you’re there.

Last week, a post I wrote, “The Myth of the Software Rewrite,” became pretty popular.  This generated a lot of comments and discussion, so I decided just to write a follow-up post to address the discussion, as opposed to typing a blog post’s worth of thoughts, distributed over 20 or 30 comments.  This is that post.

No Misconceptions

First of all, I want to be clear about what I’m talking about.  I’m talking specifically about a situation where the prime, determining factor in whether or not to rewrite the software is that the development group has made a mess and is clamoring to rewrite it.  In essence, they’re declaring bankruptcy — “we’re in over our heads and need outside assistance to wipe the slate clean so we can have a fresh start.”  They’re telling the business and their stakeholders that the only path to joy is letting them start over.

Here are some situations that the article was not meant to address:

  • The business decides it wants a rewrite (which makes me skeptical, but I’m not addressing business decisions).
  • Piecemeal rewrite, a chunk at a time (because this is, in fact, what I would advocate).
  • A rewrite because the original made design assumptions that have become completely obsolete (e.g. designed around disk space being extremely expensive).
  • Rewriting the software to significantly expand or alter the offering (e.g. “we need to move from web to mobile devices and offer some new features, so let’s start fresh.”)

A Lesson From Joseph Heller

Joseph Heller is the author of one of my all time favorite works of fiction, Catch 22.  Even if you’ve never read this book, you’re probably familiar with the term from conversational reference.  A catch 22 is a paradoxical, no-win situation.  Consider an example from the book.

John Yossarian, the ‘protagonist,’ is an anti-heroic bombardier in World War II.  Among other character foibles, one is an intense desire not to participate in the war by flying missions.  He’d prefer to stay on the ground, where it’s safe.  To advance this interest, he attempts to convince an army doctor that he’s insane and thus not able to fly missions.  The army doctor responds with the eponymous catch 22:  “anyone who wants to get out of combat duty isn’t really crazy.”


Read More


It’s Okay Not To Lead

I originally wrote this post for the Infragistics blog.  You can check out the original here.  While you’re there. take a look at posts by all of the various authors.

When I first entered the workforce, I was in awe of the programmers around me.  I’d spent 4 years of college learning how to implement Alpha-Beta pruning and various flavors of sort(), while these guys had been building things that real people used in the real world for years, or even decades.  I imagine it was, on a much smaller and more cerebral scale, the way a college football player feels upon turning pro.


This didn’t last.  After a while, I viewed them less with reverence and more as simple peers from whom I could learn, given their comparable wealth of experience.  As the years passed, the scales began to balance as I acquired more and more experience.  I was no longer the greenest developer around, and there was a healthy mix of people more and less experienced than I was.

The Path to Leadership

As this transformation took place, I started to develop opinions and preferences of my own, based on experience and on becoming a student of the craft.  I began to read books by people like Uncle Bob Martin and Michael Feathers.  And, sometimes, these opinions I was developing didn’t line up with those of some of the people around me.  I started to notice that the practices advocated by industry thought leaders were dismissed or ignored by some of the people around me.

At the same time, I began to notice that the people making technical decisions from positions with names like, “Architect,” “Principal Software Engineer,” and “Team Lead,” weren’t necessarily the best, technically.  Often, these leadership roles seemed to be as much a function of number of years with the company and familiarity with the domain as they were a function of technical acumen.  And where the developers more experienced than me seemed diverse in their skill, philosophy and approach, the decision-makers seemed disproportionately to value a “crank out reams of code” approach.  And, of course, when you have differences of opinion with the decision-makers, it doesn’t tend to go your way.

Read More


Selling Your Boss On That Shiny New Tool

Editorial Note: this was a post originally written for the SmartBear blog.  You can read the original here, at their site.  Check out the other authors over there, too.

Have you ever attended a trade show or conference that left you feeling like the proverbial kid in a candy store?  You had delectable food, met really smart people, attended eye-opening talks, and took tons and tons of notes.  The only complaint you had, in fact, was that you were forced to choose between multiple awesome sessions that were happening at once.  You were practically glowing as you said your goodbyes and headed back to your normal job, prepared to dazzle your coworkers with all of the new techniques that you knew would be real difference makers.

But even if they didn’t necessarily buy into everything to the extent that you did, there was that one tool that was just such a no brainer that it would sell itself once you explained it. But it didn’t. There’s nothing quite like having your proposal flatly and unenthusiastically rejected to shock you out of the post-conference glow and throw you right back into the daily grind. You were so convinced that people would see the incredible benefits that you find the actual results inconceivable: your coworkers shrug indifferently and your manager says, “We’re doing fine right now, so we really don’t need to introduce anything new.”  Is this situation avoidable?

I wish I could tell you that I had a bulletproof pitch that would never be rejected. Persuasion skills like that would be nothing short of a super power.  But while there’s no guarantee that you’ll succeed in selling your manager on a tool, you can certainly improve your odds.  The way to do this is by making a business case for the tool.


Read More


Mistakes Dev Managers Make

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at the site.  If you like this post, head on over, and check out more at the site.

Managing a team of software developers is a tall order. This is doubly true when the line management includes both org chart duties (career development, HR administrivia, etc) and responsibility for the team’s performance when it comes to shipping. In this case, you’re being asked to understand their day to day performance well enough to evaluate their performance and drive improvement, in spite of the fact that what they do is utterly opaque to you. It’s like being asked to simultaneously coach a team and referee the game for a sport whose rules you don’t know. As I said, a tall order.

I’ll grant that, if you’re a manager, you may have been technical at some point, perhaps even recently. Or maybe not, but you’ve been around it long enough to pick up a lot of concepts, at least in the abstract. But in neither case, if you were asked what, exactly, Alice coded up yesterday, would you be able to answer. Whether it’s due to total lack of experience, being “rusty” from not having programmed in a number of years, or simply being unable to keep up with what 8 other people are doing, their work is opaque to you.

As with coaching/refereeing the game that you don’t understand, you can pick up on their body language and gestures. If all members of the team appear disgusted with one of their mates, that one probably did something bad. You’re not totally without context clues and levers to pull, but it wouldn’t be hard at all for them to put one over on you, if they were so inclined. You’re navigating a pretty tough obstacle course.

And so it becomes pretty easy to make mistakes. It’s also pretty understandable, given the lay of the land. I’ll take you through a few of the more common ones that I tend to see, and offer some thoughts on what you can do instead.


The opacity of the development team’s labor creates a situation in which it’s easy to feel as though you don’t have control.  And a perfectly natural impulse in such a situation is to overcompensate and try to exert as much control as possible.  The overwhelming majority of folks that micromanage don’t think to themselves, “I want to be an insufferable control freak,” but rather something along the lines of, “I just need to get really involved for now while we’re facing this deadline, and then I’ll back off when things settle down.”


Read More