About 80% of my projects are failed take overs. I’ve come into companies that were $700K in the hole sitting on a giant mess. So I ask: Should I try to repair their broken codebase? Is it worth trimming the fat and doing my best with what’s left over? I make a decision based on several key factors.
What’s the quality of the code and test coverage? Is it long spaghetti code or short, tight classes? I’ll take a look at the sections of code that programmers avoid like the plague. I’ll ask, “How hard is it to make minor adjustments or debug?” Keep your eyes peeled for the Spaghetti Triangle. Like the Bermuda Triangle, it makes time, money, and resources vanish into thin air. Might want to jump ship here.
How far off are the application’s features from the business goals? Is it drowning in creep and over-engineering? How many features does your application have? How many are satisfying customer needs? This pairing should be direct, easy to understand and demonstrable.
I’d also ask what kind of feedback has been gathered and take a look at it. Have they responded at all? Have they made knee jerk feature changes? Or did they wait for significant feedback numbers and then make wise, limited modifications?
Who’s on the team? Are they an A team or a B team? For example, I look for boomerang players. By this I mean someone you send out on a task, and they come back with it finished. I shouldn’t have to monitor and chase them all the time.
When I’m called in to evaluate a project, I take the pulse of the team. How’s morale? Is everybody upbeat, or are they miserable? Are people collaborating in a fluid way or are they stubborn and isolated? No matter how great their tech skills are, if team members hate each other things don’t go well for the business.
It’s also important to consider team structure and composition. I’ll look at personality types, leadership skills, relationships, coding abilities, and how all this unifies – or divides – the team. When things are bad, it’s almost palpable. The best teams have a cheerful balance.
In the past, I completely missed the boat. I only looked at the technical aspect, and I ignored the human element. If I can’t asses the human component, I can’t lead a team. For the CTO it’s a critical skill. Team composition carries as much – or maybe even greater – weight than programming expertise.
Make the decision
Finally, the decision arises between salvaging the old or writing a new simple system from scratch. The reality? Nine times out of 10 what I encounter is unacceptable, and it’s time to abandon ship and build a new one. It takes a while to get motivated enough (or scared enough) to address the problem. By the time I’m called in, it’s usually a long standing issue, and I’m just there to confirm and triage. I’m amazed at how many companies let it get so far out of control, deep pockets I guess.
In the long run, it will usually cost more to fix a broken system than to build new one. Plus I can stand behind the new system since I know it was done right from the start.
If you’re sitting on a situation like this in your organization, ask yourself if you should build a better ship. When I’m not sure, I bring in an expert. Don’t just keep a faulty project rolling until things blow up — or until shareholders ask why it costs so much but delivers so little. If you stand there and watch it bleed, you’re responsible. If you reach out and stop the bleeding, you’re a hero.