"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.'"
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?
Sign up for CIO Asia eNewsletters.