Abandon ship and build a better one – Rewriting Systems

4 minute read
Scroll this

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.

Code quality

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.

Customer Centricity

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?

Team Composition

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.  

Own it

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.

What should you do?

When making the decision to rewrite a system or not, it might not be clear exactly what to do and this can be tricky. The people at the top in life are always working, growing and improving with the help of others. It’s how you got to where you are, and it’s how you will get up through the next stage on your journey.

I have experience that you can leverage. If you don’t use me, use someone else. The point is for you to get what is on your mind resolved immediately, don’t wait. Set an appointment with me and tell me about your situation so I can help. Click this link to reach out. Something else on your mind? Whatever you need, I’m here. Life is meant to be done together, just reach out.

Joel Beasley

Joel began writing code at age 13 selling his first technology by age 18 for one million dollars. In his first three transactions, he developed key relationships and began working with Investors and Chief Technology Officers collaborating and building products in Real Estate, Law, Finance, and Fitness.

Today, Joel is a Chief Technologist executing the Modern CTO World Tour. Joel is an author of the book Modern CTO a #1 New Release on Amazon and a #1 Technology Podcast with 70k active listeners. Joel has a clear vision and passion for modern technology, placing him as one of the most exciting Chief Technology Officers to watch out for.

Joel is the President of BeasleyFoundation.org a charity that designs STEM related children’s books Back to the Moon and Princess Physicist. These books are then donated to orphanages, homeless pregnant woman and in-need children. Beasley Foundation was formed in February 2017 after Joel, Mitch and Valerie lost their Mother to Leukemia after being diagnosed 6 weeks earlier. Joel and his siblings wanted to do something unique with her life insurance money and the Beasley Foundation was formed.

Read more about Joel

Reach out to Joel

If Joel can be helpful to you, send him a message
or schedule a meeting.

Send Message Schedule Meeting
Fresh CTO Content 24/7

Fresh CTO Content 24/7

Join our mailing list to receive relevant content hot off the press.

You have Successfully Subscribed!