I’m an amateur cook, and not a very good one.
It kills me to say it, and I wish it weren’t so, but I don’t have a “feel” for cooking. You know what I’m talking about of course, because regardless of whether you’ve tried cooking yourself, you have certainly had a meal, and you know what a tasty dish of food is all about. Some cooks have that oh-so-elusive feel for cooking. They know just the right amount of spice that a dish needs, and they know just for how long a dish needs to remain on high heat. They know what the phrase “stop cooking the pasta when it is 80% done” means. The whole armada doesn’t come to a grinding halt for these guys when an ingredient is not to be found in the kitchen. These are the sort of people who will open the refrigerator, grab something else, and nonchalantly say “Ah, this will do just as well.”
I hate those guys.
Me? I’m the mad slapdash cook. My dishes are just the wrong side of done to perfection, and “add salt to taste” in my universe means “fancy a swim in the ocean?”. I, in other words, don’t know when to stop.
But that, it would seem, would make me a good (?) coder. I’m joking, of course. But at least some coders seem to suffer from the same problem: apparently, they just don’t know when to stop.
The article that this picture is from is a lovely little rumination on “feature creep“.
Feature creep is the excessive ongoing expansion or addition of new features in a product, especially in computer software, video games and consumer and business electronics. These extra features go beyond the basic function of the product and can result in software bloat and over-complication, rather than simple design.
https://en.wikipedia.org/wiki/Feature_creep
It’s ingredient creep in my case, but potatoes, poh-taa-toes.
So why does it happen? Clive Thompson, the author of the piece, comes up with two good reasons:
Granted, some of our problems with feature creep are just pure nostalgia. We fall in love with the early version of an app, and almost like a band’s first album, associate it with a simpl’r time in our salad days; then we get all itchy and pissy when the band moves on. You sold out, man! And for their part, software firms have many excuses for why they shove in all those new features. Users demanded ’em. Sure, only 1% of people use that feature, but they’re crucial users. And anyway, we gotta keep pace with the competition. Swim or die!
https://debugger.medium.com/its-time-for-maximum-viable-product-eec9d5211156
Fair enough. But look — sometimes the enclottification of an app really just is feature creep. And you can understand why it happens! Developers love to develop; marketers want new stuff to market. Adding new features, shipping new code, is fun and exciting. Merely maintaining a successful app? Bleah. So dull.
And how should we avoid falling into this trap? Clive speaks about a concept he calls the “Maximum Viable Product”:
What if more developers developed a sense for the “maximum” number of things a product should do — and stopped there?
https://debugger.medium.com/its-time-for-maximum-viable-product-eec9d5211156
What if more software firms decided, “Hey! We’ve reached the absolute perfect set of features. We’re done. This product is awesome. No need to keep on shoving in stuff nobody wants.”
As he says later on in the article, it is just about having confidence in your amazing design.
As an economist, I would argue that what he is saying is that one should be clear about what one is optimizing for. This could be software coding, this could be an economic policy, or it could be a simple banana bread. But if it is a simple bana bread, maybe stop at the walnuts? Do we really need the cocoa powder, the chocolate chips and the cinnamon powder? And if you pop open the fridge door and begin to think about whipped cream as a garnish, that is what feature creep looks like in the kitchen.
Don’t, not-so-young lad, don’t. Stop. As Clive puts it, this product is awesome. There is no need to keep on shoving in stuff nobody wants.
Decide upon the core problem you are trying to solve, try your best to come up with a near-perfect solution to that core problem, and ignore all of the distractions. It works in the case of software, it would seem, and it also works in the case of policymaking. Always – I repeat, always – be clear about what you’re optimizing for.
And if you’re wondering, the second time around, the simpler banana bread came out much better. My 9 year old sous chef insisted on adding chocolate chips, I’ll admit, but then again, I was optimizing for her happiness.
P.S. If you don’t follow Daring Fireball, John Gruber’s lovely blog, please do. That’s how I came across Clive’s post.
EconForEverybody 