Breaking Free of Legacy Projects

Breaking Free of Legacy Projects
By Johanna Rothman

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 article. 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.

The original article can be found at: http://jrothman.com/blog/mpd/2008/08/breaking-free-of-legacy-projects.html

Johanna Rothman consults, speaks, and writes on managing high-technology product development. Johanna is the author of Manage It!’Your Guide to Modern Pragmatic Project Management’. She is the coauthor of the pragmatic Behind Closed Doors, Secrets of Great Management, and author of the highly acclaimed Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. And, Johanna is a host and session leader at the Amplifying Your Effectiveness (AYE) conference (http://www.ayeconference.com). You can see Johanna’s other writings at http://www.jrothman.com.