Sometimes someone will say “Let’s keep things simple”. Sounds appealing.
They proceed to come up with a plan containing very few steps, and they’ll all be simple steps.
This is generally a terrible approach.
Maybe it’ll work out fine, but what if you find that you haven’t done all you needed to by completing these steps? I guess you add more steps. If those aren’t enough then just keep working on it until it satisfies the requirements. We’ll clean it up in phase 2.
Phase 2 never comes.
You’ve just built something which is a lot of things, but it’s probably not “simple”.
The reason this happened is because simple things are not necessarily easy, and they aren’t necessarily obvious either. This is a common issue when building things: if you want something simple you should think, long and hard, for a while – really let the problem get into your mind, let it be a part of your own internal ‘universe’. Get to the point where you truly understand what is asked of you, and by then you should be able to make a simple plan.
The programming language Python has a set of guiding principles known as The Zen of Python. You can spend a long time dissecting and discussing the deeper meaning of all these aphorisms, but today I’m interested in just two:
Simple is better than complex.
Complex is better than complicated.
I like to imagine a lot of people think of ‘complex’ and ‘complicated’ as being pretty similar before reading this, and quite different afterwards. Comparing the two gives you the structure to help understand the striking differences.
The way I see it, a complex system has a lot going on, while a complicated system has a lot of different types of things going on: acting in different ways to each other.
Complex software is rarely your dream, but complicated software is an absolute nightmare.
This distinction is worth thinking about when you get down to brass tacks. You know what the end product needs to do, and there is no way things are going to be simple. At this point it’s worth shifting gears: you still might want to minimise complexity, but don’t let things become complicated. Consider whether an approach might need escape hatches, or edge cases, or hidden complexity. Maybe something more verbose can allow things to be more uniform, more unsurprising, more obvious.
And for the love of all that is good, don’t rush requirements out the door. It often takes a well thought-out plan to come up with a simple solution.