Knowing when to hack is a skill

I love a fast and dirty implementation that’s just good enough. If you just want to test a concept, there’s nothing better.

You get fast feedback, and yeah, it’s probably taped together, written in a single file with 2000 lines of code, and deployed by hand.

And that’s okay.

The purpose is to test something. Getting results sooner justifies sacrificing long-term maintainability.

The problem is, if you always choose speed for reliability, eventually, you’ll end up with a system that’s so interconnected and fragile that it will keel over and die.

At that point, it will be a huge pain to start decoupling things, cleanly separate concerns, tackle state management, and write tests.

It will also be hard to justify from a business perspective.

No CEO wants to hear, “We need to stop delivering business value and refactor for a few months.”

So, what’s the solution?

You need to factor in periods when you intentionally slow down a bit on features to clean up the garden.

If you sprinkle the cleanups here and there, you’ll never back yourself into a corner.

Refactors are easier on smaller codebases. The more features you add, the longer any cleanup effort will take.

The team that plans their refactoring wisely will move faster than the one that just cranks out features and only stops to clean up when things get messy, or the app starts breaking.

Yours,

Taj