What it really means to be a CTO

All kidding aside, that is the central question of being a start-up CTO. All non-business building aesthetics and measurements are out the window until you have customer #1. After that, the goal is to support the customer as best as you can. If ugly code is making modifications difficult, then you rewrite only then. If it is working, then for all that is holy leave it alone. If the code is beautiful and a change will make it ugly, then it will be ugly.

One of the lessons I wrote about goes core to this. There is more value (to a company) in learning how to navigate, manipulate, and fix large bodies of ugly/shit code than trying to rewrite it in a perfect way.

That decision was acceptable because of the complete lack of any technical experience in house (100% outsourced, multiple vendors) who had very different patterns of development. Couple this with no tests, no process and no patterns, you're stuck trying to work against something that's unpredictable.

The way forward then is to hire a team (even if it's just one guy) internally who can have ownership of code. Then instituting good practice and a sensible method of rebuild and rediscovery. Obviously this hinges on having enough runway to get into it properly.

tl;dr: sometimes it's ok to scrap it all and start again when your goal isn't about preserving code but instead is about building a better product and technical culture inside a company.

Getting downvotes - I wanted to add something: There's a real risk of making problems worse when you don't have any ability to stop and change. Working with existing code is great but when you have existing customers running into bugs on a daily basis, and fixing them would change the business logic that others are relying on, you either choose to build more technical debt or you swallow it and start again. Obviously this depends on runway, position, etc.

There are many times when companies go through their proto and raise seed only to find that their original hypotheses aren't working, and to change requires a significant re-architecture. Bolting this on to existing codebases can end up with code so complex that it won't stay up, and you end up spending six months in pure fire-fighting ops mode to keep the thing alive. Knowing when to recognize this and acting accordingly is the right approach, even if that sometimes means calling it a day on the existing code and starting again.

You have to keep the train moving. That keeps the cash coming in. You can't stop the train.

So, you have to take what you have and somehow -- that's what you are being paid for and hopefully you have the chops -- manoeuvre the beast into a better state. This is fscking hard, especially when you have to get the darn thing under test. And it's invariably massively undervalued by most biz management teams.

You can _always_ extract value from operative but shitty code, even if you have to stick your head around the U-bend and pull it back with your teeth. If you don't know that yet, then you've more to learn.