race car startup life

How to solve messy startup code in tech startups

The short answer: Don’t. Not right away.

As the Navy Seals say, get comfortable with being uncomfortable.

The longer answer: Wait until your audience validates what you’ve created. Features and single pages can also be looked at as a minimum viable product.

When Twitter launched, it famously had serious uptime problems. The core app was whipped together in literally a weekend, using Ruby on Rails. As usage grew, they stabilized, cleaned up – and tweaked direction using real-world use data.

At SwiftCloud.io – my startup – and more specifically, SwiftCRM and Swift Marketing, my CTO / lead programmer is frequently not happy with the specs given, and/or code that has a bit more duct tape than he likes.

For better or for worse, this is startup life. Perfect is the enemy of done. Slap it together (provided you’re not leaving security holes and/or destabilizing core functions) until your clients are truly getting value.

If everything seems under control, you’re not going fast enough. — Mario Andretti

As the audience grows, code will get rebuilt and refactored for stability and real-world needs. In other cases, the UI and needs evolve after some real-world use, and everything gets tweaked anyway.

Buffer aims for about 10% of their time to be spent on refactoring, and I think that’s a good loose guide. More practically, it gets balanced into priorities, and when we refactor, it’s usually for a specific reason – to make things higher performance (i.e. faster to the page), add features, solve a bug or mis-configuration, etc.

After we’re clear the function is valuable, and in use, and not likely to change much, only then do we go back and develop the nice clean waterfall style specs every coder dreams of.

Published by

Roger Vaughn

RogerV is the CEO and founder of SwiftCloud, a social business platform for CRM, marketing, accounting and more. He lives in Los Angeles, and wears many hats - including CEO, father, UI/UX dev, coder, staff coffee delivery man, and whatever else it takes to move the needle.

2 thoughts on “How to solve messy startup code in tech startups”

  1. Early startup mode certainly warrants letting code get messy, but your engineers will get upset if they have to spend their days working in unmaintainable code. It will erode morale and permit buggy code. Yes, Twitter survived poor quality code until they made the decision to do a full-stack rewrite. However, many companies don’t survive. The arguments can be made for both sides then:
    – No point in writing perfect code, we may not be here tomorrow
    – Of course we’re in it for the long haul, so we should make things nicer for the next person who has to look at this

    As an engineer, I’m living the balancing act of what’s “right” versus what’s “right now”? I burn a lot of hours figuring out someone else’s “right now” code.

    1. Brian-san – The moment one knows it’s valuable enough for real-world users to be happy, then any duct tape should get pulled / cleaned / rebuilt.

      Also, our team writes good code from day one. Their complaint is really along the lines usually of feature drift, feature creep, and wishing they had clean waterfall-style docs from day one. Usually, we find, after some real-world use we tweak things a bit even if it’s just UI and not really underlying code.

      Anyway, good point – it’s balance and there’s not a single magic-bullet answer.


This site uses Akismet to reduce spam. Learn how your comment data is processed.