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?

"We said we're going to invest in a fundamentally different model," Jacobson says, "a more optimized model that is not one-size-fits-all -- and it's going to be at some cost to my teams to execute and to the other teams who have to consume from it rather than from the previous one. We need to take a chance here and have confidence in ourselves and go for it. That's what we did. And it worked."

The creaking new construction

New construction always leads to some settling. The pipes rattle. The beams creak. But when it keeps happening, you may start to wonder: Is this normal, or does it need repair? A wise product manager once said about newly launched code: "All new babies cry." She was letting users know the system wasn't broken -- it would eventually settle down.

"Parents learn the difference between cries," says Sweeton. "Some are best left alone. Others are the genuine article distress call. Run -- don't walk -- to handle. The same is true in software development."

Dave Sweeton, chief technologist, Stout Systems"Parents learn the difference between cries. Some are best left alone. Others are the genuine article distress call. Run -- don't walk -- to handle. The same is true in software development."

--Dave Sweeton, chief technologist, Stout Systems

Determine the minimum viable product, Sweeton says, and focus on that. While you're nailing it down, figure out what can wait. "Maintain a list of all other items that will need attention, but defer them until after the first release."

You have to be clear-eyed, says Jacobson. Look at the reality of the situation and assemble the evidence. Then make your recommendation. Here, metrics for assessing the health of the project -- and the cost of healing it -- is key.

"It's not just that l have this great idea, or I didn't build it, so I want to build my own thing. Say: 'We've talked to this number of developers, we're churning this number of development hours fighting against this system, we're exposing greater risk to our availability because we're handling this number of requests. We're actually producing complexity and bugginess,'" Jacobson says.

If the current model is faltering under its own weight, he adds, it's time to create a stronger and healthier option for the future. "Whatever those metrics are -- those data points that are exposing the weakness of the current system -- they're fuel to say, 'This needs to go away.'"

The retrofit

Increasingly common is the case in which the foundation is solid, but the techniques that produced it are dated. The technology used may have been the right choice at one time but no longer. Maybe too many dependencies are no longer supported. Or it relies on old tech that few people know how to support anymore. Can you prop up this project and keep it going, or is it time to call in the wrecking ball?

 

Previous Page  1  2  3  4  5  6  Next Page 

Sign up for CIO Asia eNewsletters.