"Make It Work, Then Improve It." Is That Really True?

I've come to the conclusion that this mindset can be dangerous, because when we think this way, we end up getting used to just making things work and forgetting to improve them afterward. This is something very common, especially for us developers, but in certain situations it does make sense, for several reasons.

We use methodologies that even apply these concepts (and just to be clear, I'm not criticizing or judging them harshly), I'm only offering a slightly different point of view on the subject, since many teams use them as a basis to organize and manage project demands.

Why don't I carry this mindset with me?

As a developer, I know that seeing something work is a mix of satisfaction and joy at the same time, but making it work doesn't mean you've found the best solution. And that's exactly the point I want to make.

Think about it with me: what if we changed the mindset of "make it work and improve it later" to: what's the best solution to solve this problem?

Here I'm not even getting into topics involving design patterns, code, or architecture, but rather the product itself that you're working on.

Many times we treat an application or piece of software as if it were just something cool I'm working on, or even something that pays my bills, and that ends up stripping away not only its importance, but also the perception that it's a product, one that's scaled to many users who rely on it.

Not only that, but there's an entire ecosystem around that product, and you're not the only person who's part of it. That's why you need to think about good solutions to solve the problems of the product you're working on, in addition to writing code that's easy to read and maintain. That matters.

That's why asking questions like:

• What's the best solution to solve this problem?
• Does the solution I found actually solve the problem, or is it just a quick fix for now?
• What side effects could this code introduce into the application?
• Will another developer understand what I did here in the code?

A small illustration

Imagine you bought a new house, right? It's beautiful, it has a really solid structure, and it stands out among the other houses in the neighborhood because it was just built.

Over time, the house starts to show some problems and you realize you need to do some renovations to keep it up and to prevent other, worse problems from showing up.

The same thing happens with an application or piece of software. They get built, but they need constant maintenance, not only to fix bugs that are found, but also to add new features to always deliver the best experience to the user.

Conclusion

If I only think about making it work, I'll never worry about finding the best solution to solve the problem; instead, I'll just grab the first solution I find and that's it.

Besides being a bad thing, it makes the code harder to maintain and shortens the lifespan of the software or application.

That's why today I don't carry this mindset with me. I might take a little longer to solve the problem, but at least I'll have explored every possible scenario to solve it in the best way.