Overcomplication and overengineering are some of the direct consequences of overplanning—a common trap I’ve fallen into countless times. This can happen on almost all software projects. It often results in a huge amount of wasted time and energy and an overcomplicated outcome.
We learn the most when things happen to us, and that’s the way it has always been. We may even hear useful advice directly related to our future situations, but bury it deep in our memories. Then, we face the same issues ourselves, forget about the advice, get hit, and become the tellers of the experience for the next generation.
Anyway, this is another experience I wish I could share with my younger self: Trying to reach perfection on paper is pure poison.
Table of Contents
Open Table of Contents
But Why?
Mainly, you don’t know what you don’t know. The way to discover what you don’t know is to encounter it. When you dream on paper, things may shift from reality, and you may not see the whole picture.
The wrong bottlenecks may be identified, the wrong solutions proposed, and the wrong problems solved. You might even address a problem that doesn’t exist or is less important than other aspects of the system. Overengineering is a common mistake in this scenario, one I used to always make. It’s hard to foresee all the challenges in a system you haven’t designed.
Additionally, overplanning can oftentimes be a shield, a safe zone, or a procrastination technique to avoid being “vulnerable” to new experiences. It’s easy to get lost in the planning phase because it’s a lot more comfortable than the “actual” work.
The catch is that it won’t keep us safe. Instead, it brings overthinking to the table. Sooner or later, decision fatigue, analysis paralysis, and burnout will also follow.
What to Do?
Condition number 0 is to identify when you’re overplanning. Be aware of the time spent on whiteboard daydreaming. You know it when you know it. Then, act:
Prototype
The solution is to prototype. Make it work. Identify the “core” feature(s) and produce a Minimum Viable Product (MVP) in a day or a week. With each iteration, you’ll see more, just like exploring a dark cave—the deeper you go, the more you see. You’ll identify bottlenecks, challenges, problems, and solutions, gaining a comprehensive view of the project.
Keep in mind that this isn’t an absolute solution. Systems closely aligned with a structured model, like implementing a whitepaper or an algorithm, may benefit more from planning. However, for the average CRUD system, the planning phase often proves to be nearly useless.
Personal Experience
I spent the last ~3 years developing an end-to-end encrypted, offline-first, multiplatform, multilingual Personal Knowledge Management (PKM) system called Yaad. Initially, I spent a LOT of time in the planning phase. I created countless architectures and diagrams, filling many papers and one PowerPoint slide after another:
… I spent two years casually reading about it, writing documents, and learning about new technologies while being a university student. This was my first mistake in this journey. I should’ve built prototypes and expanded my skill set in creating a second brain over and over again, instead of drowning in the theory of it and reading about Native vs. React Native vs. Flutter vs. Cordova vs. Compose Multiplatform vs. [INSERT_YOUR_FRAMEWORK_HERE].
I wrote Yaad for a month. It ended up being so over-engineered that I found it easier to start from scratch…
Yaad Blog1
That was a hard lesson learned. I should’ve prototyped more, built more, and learned more by doing, not reading. There were many greater lessons learned in the process, but this one is the focus of this post.
Conclusion
Don’t Overplan, Do Prototype!