I’ve learned to overcome the initial complexity of a task by breaking it into small meaningful cycles.
All complex systems that work evolved from simpler systems that worked. If you want to build a complex system that works, build a simpler system first, and then improve it over time. - John Gall
This makes a lot of sense. Building something any other way would only result in analysis paralysis. I’ve seen this a lot at work - We want to build this complex functionality, no one knows how it’ll work yet. No one has been here before.
It’s okay, that’s why we’re engineers. We’ll figure things out… Everything’ll be fine, except the product has to launch now.
So we’re faced with 2 constraints
- We want the feature to ship as fast as possible
- We want it well engineered
Everyone knows you can only pick one option. So management go with option 1. Ship tomorrow.
There’re 2 things that could possibly happen:
- We ship in the shortest time possible, it works, & we put out a plan to optimize it
- We ship, it works, then we all go home and work on something else
Everyone would prefer option 1. But from my experience, it never happens. If something is temporal, it’s permanent. After this realisation, my immediate response to we’ll fix this later is…
How and when?
If there’s no well enforced process to fix it later, then it’ll never be fixed. It’s hard to see this if you’re the one writing the code.
So what’s the solution?
If there’s no solid process to optimize code after shipping, then take your time to optimize as you write
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live - John Wood