I came for the title but I don’t see a lot of value in reiterating what we already know: less data is better, less external dependencies is better, having a clear API is good.
What I hoped the article would touch on is how we can apply Ikea’s simple, pragmatic, not-fancy-but-also-not-ugly philosophy to programming. Making informed decisions about tradeoffs between functionality, polishing and cost is still one of the biggest challenges in product development for me, and there is something about this that Ikea seems to get right.
Agreed. I like when folks take the time to write down what some call “common sense,” because most of the time it very not is, and it is very insightful to read even things we agree with.
What I hoped the article would touch on is how we can apply Ikea’s simple, pragmatic, not-fancy-but-also-not-ugly philosophy to programming. Making informed decisions about tradeoffs between functionality, polishing and cost is still one of the biggest challenges in product development for me, and there is something about this that Ikea seems to get right.
I think we definitely have the same values, and I’m still searching for ways to communicate these concepts. Off the top of my head, here are some principles I personally use for making my unfancy software:
In terms of balancing perf/cost/polishing/etc, here’s a few rules-of-thumb I use:
Above all else, don’t make things worse.
How would you build your software if you were shipping it on an N64 cartridge and couldn’t make updates?
When an ugly app breaks, people say “this app sucks”. When a pretty app breaks, people say “whoops, I did something wrong”.
Don’t touch a single CSS file until everything works without bugs.
I have a lot more essays these types of things in the works, but writing takes a long time :) Let me know if there’s anything in particular I should prioritize.
I guess my open questions come from the context of developing a large software product with about 300 developers. There are hundreds of well-documented medium priority bugs, a significant number of long-standing high priority bugs and a thousand valid feature requests. Besides that we have the points mentioned in the article: there is ample room for optimizing the application size and compile times, to replace dependencies with in-house code or improve the internal API consistency of legacy code.
You can only work on say 5% of all these important tasks; which ones do you pick?
I’m sure Ikea deals with similar questions, though mapped to different dimensions: there is a long list of user studies that point out how customers struggle to put their product together, there is a long list of ideas for how the products can be made more functional or sturdy. Besides that, packages could be made smaller by making the boards thinner, screws could be made to require no tools at all by making them from plastic, and wood could be sourced cheaper at the cost of a good visual appearance.
I’d be curious to know how Ikea decision-making works to balance all those conflicting needs.
I’m super curious about this too. I’ll try to send an email to IKEA international and see if they’ll answer some of these questions.
It seems like companies like IKEA, Apple, LEGO, and Teenage Engineering have an advantage because every person in the company probably knows their products really well and can make a good guess about quality vs. speed. I’m sure it’s much easier to prioritize things as a company when every person in the company has a similar vision.
Quality versus speed is the right question. But I think what people wish for isn’t possible. I.e. estimations don’t work, and people cannot know the difficulty without an implementation.
My personal answer is to build feedback loops that allow people to gain information at a lower cost without committing them to a bad or expensive idea:
“how can we slice this thinner? Can we build a spike? When do we know it is ‘good enough’? Do we have a process in place for continuous improvement that allows us to iterate on quality after it shipped or do engineers feel they have to get it ‘perfect’ otherwise they will never see it again?
I think that this is a question of values. What exactly does your product do? What should it never do even if people want it to? Tons of customers might ask for their Honda CRV to win a Grand Prix but that’s out of scope.
It would be really interesting to hear how ikea handles this value problem and the focus. I’m guessing they have some minimum requirements “must be able to X” and then within that there are some easy/guaranteed wins. If you can make it cheaper to build or ship and still meet minimum requirements then you’re your team should do it. For other questions of functionality and issues I think you need to build feedback loops.
With a team that large possibly have rotations. Maybe one team shadows support and answers support tickets for one week then the next they do their own prioritization and fix issues they found. Another three teams spikes out three different major features and then at the end they compare difficulty and benefit and collectively choose one to implement.
To me “what do we work on next” is less interesting than “how do we incorporate feedback so we can correctly reprioritize ongoing work (I.e. gaining information while implementing it) and how can we align our engineers with our customers and give them the tools to build autonomy, mastery, and purpose”
I came for the title but I don’t see a lot of value in reiterating what we already know: less data is better, less external dependencies is better, having a clear API is good.
What I hoped the article would touch on is how we can apply Ikea’s simple, pragmatic, not-fancy-but-also-not-ugly philosophy to programming. Making informed decisions about tradeoffs between functionality, polishing and cost is still one of the biggest challenges in product development for me, and there is something about this that Ikea seems to get right.
I see a lot of value in expressing ideas in different ways. It’s a thought exercise. I found it well expressed.
Agreed. I like when folks take the time to write down what some call “common sense,” because most of the time it very not is, and it is very insightful to read even things we agree with.
Author here :)
I think we definitely have the same values, and I’m still searching for ways to communicate these concepts. Off the top of my head, here are some principles I personally use for making my unfancy software:
for-loopIn terms of balancing perf/cost/polishing/etc, here’s a few rules-of-thumb I use:
I have a lot more essays these types of things in the works, but writing takes a long time :) Let me know if there’s anything in particular I should prioritize.
Thanks for those points and links.
I guess my open questions come from the context of developing a large software product with about 300 developers. There are hundreds of well-documented medium priority bugs, a significant number of long-standing high priority bugs and a thousand valid feature requests. Besides that we have the points mentioned in the article: there is ample room for optimizing the application size and compile times, to replace dependencies with in-house code or improve the internal API consistency of legacy code.
You can only work on say 5% of all these important tasks; which ones do you pick?
I’m sure Ikea deals with similar questions, though mapped to different dimensions: there is a long list of user studies that point out how customers struggle to put their product together, there is a long list of ideas for how the products can be made more functional or sturdy. Besides that, packages could be made smaller by making the boards thinner, screws could be made to require no tools at all by making them from plastic, and wood could be sourced cheaper at the cost of a good visual appearance.
I’d be curious to know how Ikea decision-making works to balance all those conflicting needs.
I’m super curious about this too. I’ll try to send an email to IKEA international and see if they’ll answer some of these questions.
It seems like companies like IKEA, Apple, LEGO, and Teenage Engineering have an advantage because every person in the company probably knows their products really well and can make a good guess about quality vs. speed. I’m sure it’s much easier to prioritize things as a company when every person in the company has a similar vision.
Quality versus speed is the right question. But I think what people wish for isn’t possible. I.e. estimations don’t work, and people cannot know the difficulty without an implementation.
My personal answer is to build feedback loops that allow people to gain information at a lower cost without committing them to a bad or expensive idea:
“how can we slice this thinner? Can we build a spike? When do we know it is ‘good enough’? Do we have a process in place for continuous improvement that allows us to iterate on quality after it shipped or do engineers feel they have to get it ‘perfect’ otherwise they will never see it again?
I think that this is a question of values. What exactly does your product do? What should it never do even if people want it to? Tons of customers might ask for their Honda CRV to win a Grand Prix but that’s out of scope.
It would be really interesting to hear how ikea handles this value problem and the focus. I’m guessing they have some minimum requirements “must be able to X” and then within that there are some easy/guaranteed wins. If you can make it cheaper to build or ship and still meet minimum requirements then you’re your team should do it. For other questions of functionality and issues I think you need to build feedback loops.
With a team that large possibly have rotations. Maybe one team shadows support and answers support tickets for one week then the next they do their own prioritization and fix issues they found. Another three teams spikes out three different major features and then at the end they compare difficulty and benefit and collectively choose one to implement.
To me “what do we work on next” is less interesting than “how do we incorporate feedback so we can correctly reprioritize ongoing work (I.e. gaining information while implementing it) and how can we align our engineers with our customers and give them the tools to build autonomy, mastery, and purpose”
This is a good point! I recognize that giving engineers a somewhat accurate impression of what users think and need is definitely not easy.
So to further the Ikea analogy, that would mean that the package manager should be obnoxious and impossible to navigate like their stores.
Some percentage of any application’s users are not using it for the intended purpose, and are only there for the meatballs?
You just have to learn to always go through the package manager backwards and look for the shortcuts in the walls?
Turns out every language has followed this practice from the beginning already! We’re ahead of the curve.
In fairness there is no telling what things will be like in twenty years. I would be willing to stake a bet on C and C++ code, but not much else.
Good rule-of-thumb for estimating lifetimes: https://en.wikipedia.org/wiki/Lindy_effect
My blogging engine is 23 years old now. It is also written in C.