Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How to salvage a (nearly) hopeless software project

Paul Heltzel | Jan. 6, 2015
Like a carpenter called in to salvage a home repair gone wrong, developers who've been around the block are used to seeing a handful of the same problems. The code gets creaky; bug reports file at an ever-increasing clip; the time spent maintaining the project surpasses any ability to add features to it. At a certain point, the question arises: Can you rehab the code, or should you scrap it and rebuild from the ground up?

"When prioritizing, you're basically saying: 'Which things are we going to do today or this week?" says Netflix's Jacobson. "The right question is: 'Do we care about this at all?' And if we do, then make it happen -- and if we don't, then make it gone."

The castaway

It's not uncommon for a software project to simply be left unfinished, with the developer AWOL. Perhaps the core has been sketched out, a few features have been implemented, but the contractor, dev shop, or employee who launched the project simply left one day, never to return. The code works, barely or not at all. Or perhaps the project was completed but lacked a maintenance plan and is now falling into disrepair. What next?

First, the bad news: If you did the hiring, there's not much point in finger-pointing.

"If one person created the whole thing, the problem may be the manager," Jacobson says. "And if you're the manager, you've done a poor job."

All of our pros offer the same tip: Avoid it in the first place. One way to plan for this contingency is to cross-train the team to ensure more than one person understands the source code.

"Let's say the team working the project has six developers," Estrada says. "One is working on some of the functionality for online payments, another person is doing personal account management or presenting data to the user. You switch them over. Rather than assign the person who built the original functionality, get a different person to fix problems or create new features. They get exposure to that area and the source code. If the person working on account management gets lost in some foreign trip and never comes back, somebody else can still pick it up without much struggle."

If consultants are creating the code, Sweeton says it's still important to get multiple developers in the loop: "Engaging a lone consultant has inherent risk if you don't have direct-hire developers on your staff. Make a direct hire or engage a consulting company that approaches the development project with resource redundancy."

The money pit

The bills for this makeover are so extreme it would make a spouse -- or accounts payable -- flip out. The architecture had problems from the start, and predictably, boatloads of cash didn't solve them. How do you stop throwing good money after bad?

Sometimes the instinct is to prioritize and dig your way out. But then you end up with a long list where everything -- and nothing -- is urgent. Time goes by, more issues are reported, and the result is a backlog that would take years to resolve.

 

Previous Page  1  2  3  4  5  6  Next Page 

Sign up for CIO Asia eNewsletters.