Make it WORK then Make it BETTER

Vadivel
Vadivel
Aug 27, 2017 · 2 min read

In my nearly 2 decades of experience, I have seen teams strive tirelessly to “Make it work” and deliver a minimum viable product but are indirectly forced to skip the “Make it better” part due to lack of time/bad estimation.

Why?

Because once the minimal viable product is made people start pulling resources out of that, start assigning next module so that they can “Make it work”. The assumption was we can work on refactoring the code tomorrow or day after which in reality never happens. Ultimately the development folks don’t find time to “refactor” their initial code to “Make it better”.

“The problem with waiting until tomorrow is that when it finally arrives, it is called today.” — Jim Rohn

So what? It is already working anyway!

“Make it work” which is not followed by refactoring sessions to “Make it better” will undoubtedly break down when we start to scale. Over a period of time code base would become complicated & the cost of change at that time would be too high which might even jeopardize the business altogether.

Make it work
- If need be, do research and implement a solution to achieve the desired behavior/result.
- The solution might not be having a good design,
- Code will not be optimized and
- It won’t be easily maintainable.

Make it better
- Now that desired result is in hand, refactor the code.
- Organize the code base properly to have a good design and
- Make sure it’s maintainable.
- Optimize the code to achieve the desired performance goals of the application.

)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade