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 talked with seasoned pros for insights on how they have addressed the most common types of software projects on the brink: Projects with runaway costs, poorly architected projects, ones that simply no longer work.
This is our wrecking crew:
- Daniel Jacobson, vice president of edge engineering at Netflix, where he was brought on to lead the API team
- Stefan Estrada, an engineering manager at Verizon who oversees a team of five developers working on the OnCue streaming TV service
- Dave Sweeton, chief technologist of Stout Systems, a consultancy often called on to take over or repair projects gone awry at Fortune 500 firms, among others
Now let's take a look at our fixer-uppers.
The patch-up job
Not every software project kicks off with a bulletproof plan and a crew of fabled "10x developers" to execute it. Instead, you often get a kind of "homeowner's special" -- a pile of code cobbled together to solve an internal need using the skills of those on hand. In these cases, success can be a curse. Over time, this DIY effort, essential now for business purposes, becomes a tangled mess of bolt-on code and superfluous frameworks, and the only way forward is to bring in an experienced crew and hope for the best.
"There could be many culprits in a scenario like this," says Sweeton, of Stout Systems. "A common one is some fundamental flaw at the architectural level, so the framework of the house doesn't support what you're trying to build. That can be too little framework or too much framework -- too much is actually more common than you'd think."
If you're lucky and the bones are good, you may not have to tear down the whole endeavor and start anew.
"This is where the buzzword refactoring comes into play," Sweeton says, adding that the first step in refactoring code is to return to its requirements.
"I would understand the requirements, then review the code to see if it's meeting those requirements -- and unstated ones like quality and maintainability," Sweeton says. "If there are architectural problems, then sort out what it really should be and figure out the way to get the right architecture in place."
This doesn't always mean rip and replace. As with a house, when you run across problems with code, there are ways to improve the overall situation instead of merely fixing the previous owners' mistakes. Make incremental fixes and every time the code needs work, add an enhancement -- right the wrongs, Sweeton says. And refactor, refactor, refactor.
Sign up for CIO Asia eNewsletters.