I just googled and found this quote from Oliver Wendell Holmes: “I wouldn’t give a fig for the simplicity on this side of complexity, but I would give my life for the simplicity on the other side of complexity.”
---
In software development we tend to try to fill the mug up as high as we possibly can. What do we fill it with? Features.
That's wrong.
Over the last few years I've concluded that we'd do better to spend more time up front figuring out why (a) we we're building our product and (b) how we can make it as simple as possible. To mix up two of my metaphors, we should try to spend time up front getting our product/project's lede right and, as part of that exercise, we should endeavour to make GOOD COFFEE rather than LOTS of COFFEE.
Now, you might think I'm arguing for a switch to waterfall. I'm not. Waterfall's mistake was trying to set the requirements & solution in stone, early in the project, long before they should have been. I don't want that. Instead, I want us to spend a little more time thinking about things like sellability (not a word, but a measure of "how easy is this product to sell?" - I saw a talk recently at a Scotland IS event where the speaker (sadly, since deceased) showed that smaller, simpler products were far easier to sell in B2B) and testabiity (not a word, but "how easy is this product to test" - I can't prove this but my gut says smaller products are simpler to test). Sellability is important because, well, that's the reason we build the product. Testing capacity is very often a dev teams internal constraint and if a product is easier to test then the team is normally more productive and faster to finish and able to ship more products/releases.
But, here's the problem: how do we create simple products?
Way back in 2004 I wrote about (what I call) the Paradox of Simplicity - where we undervalue simple solutions because they look easy but overvalue complex solutions because they look hard and clever and BIGGER. Intuitively we tend to think that if a solution is easy then the people who created it could get a better solution by putting in more time and more effort. And that's true, if the solution is indeed easy, but what about when the solution is not easy, but simple?
Thing is: Simple, comes after complicated. The sequence goes something like this: EASY, COMPLICATED, SIMPLE.
So, I have some questions for you: is SIMPLICITY just a matter of spending more time and pushing past the complicated? Or, do you need a genius like Steve Jobs to get you there? Is it just a matter of realising that your goal is simplicity, rather than complication? Is it something else?
---
To take this whole post and simplify it: can you tell me how to do just enough up front thinking so that I come up with a simple saleable, testable solution?