Breaking Free of Legacy Projects

If you’ve never been a victim of Medieval software project management, wow, I’m impressed. You don’t have to read the rest of this post. But if you’ve ever tried to break free of a legacy product/project, and haven’t been able to, you are not alone.

The problem is we can’t create a knowledge management system that can copy everything in a developer’s head. So we attempt to keep the developer chained to that product, only to break free if he or she leaves the company. I left a job, and the company asked me to keep a listing of all of the files for that product. I explained I had a limited short-term memory, once I started with other things. “But what if I need you?” the manager wailed. “How else will I know what’s in the code?”

Uh, read the code. That doesn’t always work–some people like to make complex code. Or maybe, their code needs to be complex and I just don’t get it. In that case, read the tests. Oh, there are no tests? Hmm, maybe pair-write the product before you get into the one-person-one-product conundrum.

Here’s what I did when I was a manager inside organizations, and what I suggest to clients now: make sure a team works on each project. That means no single-person projects, ever. A team to me contains all the people necessary to release a product. Certainly a developer and a tester. Maybe a writer, maybe a release engineer, maybe an analyst. Maybe a DBA. Whatever it takes to release a product, everyone’s on the team. Everyone participates. If they can automate their work and explain it to other people, great. But it’s not a team unless the team can release the product.

When enough other people know about the insides of a product, it doesn’t matter if all the developers leave–the testers can explain what’s going on. Same if all the testers leave, the developers know. If all the writers leave, the testers and developers know what’s going on. Sure, there’s a learning curve, but no one is hamstrung by legacy projects.

There is no such thing anymore as a single-person project. If all you’ve got is one customer, you’ve still got a two-person project.

Managers create legacy projects because they don’t understand productivity and capacity. What managers need to care about is the number of projects a team can complete per unit time, not how busy any one person is. If you can’t complete n project because you’re still fixing legacy project (which was project n – 4), your manager is not being effective and neither are you.

If you have a legacy project, insist on a team to finish it. Or, if you’re like me, you quit after a while because you didn’t get the team and you couldn’t take it anymore.

If you’re a manager, count those legacy projects, and stick them in your portfolio to either finish or kill or park somewhere if you really think you can’t kill them outright. But stop the partial-staffing of legacy projects. That’s nuts. Either staff it or not. Don’t make people leave because you can’t decide what to do with this project.

9 Replies to “Breaking Free of Legacy Projects”

  1. I inherited a legacy project in the early 1990s. The source code was hard to understand and there were no tests. To keep the project from being dependent on one person, I wrote a set of detailed procedures on what we should be doing. Those procedures were gold as the project took on life and grew to a team of a dozen people. Each new person received the procedures and was able to contribute on their second day.

  2. Although having a team has it’s positives. The less people developing a product results in fewer defects. There should be less defects because there is less collaboration needed. If a one man team can write a piece of software, he usually is forced to write it better because he can’t just divide it up. Basecamp/Rails is a good example.

  3. Every project is a potential future legacy project, and many of them will wind up there. This is why design documentation is important, no matter how much it is out of fashion. Yes, it’s hard to keep documentation up to date. So what? The difference between a cowboy coder and a professional software developer is knowing that there’s more to a project that the code, and that the code is sometimes the easiest part of the project.

  4. I can’t agree with Joshua. Not only because one person projects expose the organization, as Johanna points out, but because better work often results from the synergistic effects of two or three person teams, even when one person has all the to get the job done. One person projects are a problem in any organization. When I managed a software development group I inherited many of these projects, several of them legacy projects that never ended, and immediately reorganized to put a stop to them. Result – productivity increased considerably. An additional note, I have never seen data which states that defects are inversely proportional to the size of the development team. In fact, I have seen data on very small projects that says defects per line of code are quite high.

  5. Pingback: Reproducible Ideas » Blog Archive » Medieval project management
  6. “The less people developing a product results in fewer defects.”

    I agree with this in itself. But then again, it must have a lower limit on it. A three-person team is probably better than a twelve-person person one (too many cooks?), but is it better than a four-person team?

    Philosophizing aside, Johanna makes a valid point about the difficulty of creating maintainable software.

    “If a one man team can write a piece of software, he usually is forced to write it better because he can’t just divide it up.”

    A piece of software is a living breathing thing, or at least it should be. The point is not that a single person cannot write good code; it’s about what happens to projects when that single person will not maintain the code.

Leave a Reply