Do it the right way vs. do it the fastest way

When I discuss features with engineers, I often get questions like this:

• Shouldn't we do it the right way?
• Are we creating too much technical debt to get this feature by the end of the month?
• Instead of doing it in a quick-and-dirty way, let's do _____.
• If there were no time pressure, we could have designed it in the right way.

These are questions that I would call design-and-speed trade-off questions.  These questions assume one thing.  The assumption is that we have to make trade-off between well designed feature and time-to-market.

If we spend time designing things, that will push out the implementation cycle, and it will take longer to implement.  Hence spending time to design is an overhead that competes with time-to-market.  This stems from the following beliefs:

1. More design will mean longer implementation cycle.
2. Better design is one that is more future-proof.
3. Great design is determined by how modular and reusable the code going to be.

Sadly, these are wrong understanding of what design is about.  Design is a process through which engineering and product management team create the simplest possible thing that solves the problem at hand.  There is only one thing that differentiates the great design vs. poor design.

It is simplicity.

Here's why.  I don't care what your odds of predicting your future might have been.  But I can tell you that no one really knows what kind of interesting use cases and future requirements are going to be showing up on your feature backlog.  That includes engineers and product managers (surprise!).

Because we pretend that we know what will be asked of us in the future, we try to predict what will happen, and over-engineer the solution to make it future-proof.

Don't do it.  Spend that energy instead thinking about how to make the simplest possible solution.  If it's simpler hence easier to implement, do it that way.  Modular code is easier and simpler to understand.  That's why people talk about modular design is a good design because it's simpler, not because it's future ready.  Because it's simple, it is easier to understand, hence it's more likely to be picked up by some other engineer to be reused.  No one will reuse something that they don't understand.

So the question should be this:

Can it be any simpler than what we have to get it done faster?