The real world is infinitely more standardized than virtual ones.
Physical space itself enforces a set of laws that make any two objects "compatible", regardless of any established interoperability agreements.
However, in software, there is no such constraint. Two randomly chosen software components are, in general, less composable than a chair and a galaxy.
This is the core reason why we have only been able to achieve interoperability in very specific domains. It's not because we're bad at design or planning --- it's because the space of ideas itself is simply so overwhelmingly large that it takes time and incredible coordination to get anything like pre-built IKEA blocks which fit together naturally.
I work full time as a software engineer, and I also spend time writing code on side projects. I love working on my side projects because it means I get to spend a bunch of time learning the quirks of whatever tooling and frameworks I decide to use. I often develop opinions and personal standards that I bring with me to future side projects (and sometimes $dayjob), although I've never quite stood up all the components of one of my projects "quickly". I'll always find something to tinker with and learn about, which I think is acceptable for my personal projects, desirable even.
As I get more personal projects under my belt, I believe I'll be able to stand up projects more and more quickly, although it's never perfect. Even though I've been using a similar stack among my side projects for a couple of years now, dependencies get outdated. Sometimes you gotta jump to a new major version. Sometimes you wanna try out the "new way".
I like the idea of building up my own personal stack of tooling, frameworks, and patterns that I use, and could even encourage the use of at $dayjob, but for the reasons outlined above, I agree with the conclusion of the article, which is that an "IKEA of software" doesn't exist currently.
For now I'll keep happily tinkering in my side projects. This article was a good read.
I don't think the ikea analogy works. Ikea is like a low code solution, which the article also mentions as being too limiting. If you can't design the closet you want in the ikea pax or platsa system, you're also out of luck and will need to get something completely custom built. Especially since the paper honeycomb Ikea furniture doesn't lend itself to modifications.
I've seen this reusable assembly of software components again and again in the discussions for decades as well as in some older research papers. One side it's good that we check periodically if it can be done with any new tech that is available.
But has any efforts made it far that is universally plug and play? Open source projects had come close. Now those OS projects used by AI coding assistants come close. But no so much plug and play. I think I know why it wasn't happened, and may be can happen.
But I think the idea of abstractions in software engineering, which has guided OOP and even the classes today, is because it was somehow pioneered and may be natural to us to think of the systems that way. Abstractions change from person to person and from teams to teams. Two fleet system components for the same purpose built by two different team will internally behave differently. So universal plug and play for same flows might not work as we think it should be.
Even a low code/no code components, which has a high reusability among completely different projects by different people may introduce overhead that will not work for a said system? because their abstraction of the system isn't the one same as the component was designed? They end up reusing the abstractions of how the system should be around what is already there.
Whats happening now with AI coding assistants, would be the reusability of components software as it should be in this engineering world. It reuses the approaches from any OS project, we can even alternate between the approaches and we get the best out of it (if you know what you're doing) from the different choices and also via our own abstractions of how software should be.
I think we are there, antifragile way of software reusability. We should embrace the choas. A universal metaphorical plug and play for software engineering.
Twilio's Flex isn't far off this concept. For building simple voice and text message applications, it does quite a lot out of the box. It's their full telephony stack but presented at a much higher level of abstraction.
It’s interesting because there is a view that we already have this. You can deploy most of the infrastructure you need to do the kind of thing the author is talking about using a few hundred lines of docker-compose.yml. The author alludes to some of that - grafana, postgres, etc.
What is missing is the glue, or the business logic, or maybe just the custom frontend you can charge a lot of money for ;)
Using any blogging software and stripe or square or paypal you can setup an online store that comes close to the experience that shopify offers - to the customer. But the backend is nowhere near as good as shopify - you are copy-pasting addresses over to usps or ups, tracking orders with notes attached to stripe payments, and god forbid you should want to automate any transactional emails related to it. Oh, and your system falls apart when you start taking orders via ebay or etsy - since you linked so much process to stripe. So the whole thing devolves into a carefully crafted google sheet.
Which is all to say, i agree with the author - but i feel like we are winning the war, it’s just the battlefront moved from deploying backed services to gluing the pieces together.
>Software would be decoupled from its creator, very much in the same way writing decouples information from the writer or video decouples content creators from their content.
"top-to-bottom" needs a better name that doesn't omit the "reverence for the artisans" (aka supply chain nous) that's in IKEA's DNA
Probably those SAP, Salesforce ServiceNow folks come somewhat closer?
Like the author says - fleet-tracking system, a bus-ticketing platform or IoT platform share some basically similar requirements. And this is what those SAP types offer - standardised templated versions of workflows.
But slowly, as they get more and more standardised, they start feeling like calcified systems that the end users start hating. Because they are now forced to work as per the templates.
And then the need for customization. And move beyond IKEA-like standardization.
The comparison to artisanal furniture really lands because we do spend way too much time on the basics. It would be nice to just assemble the pieces we need and move on to the interesting work.
People have been building low code or modular software components for decades - at all layers of the software stack- eg compilers, languages, frameworks, libraries, components, platforms, extensions, you name it..
Just some examples over the years
Odoo, flutter, eclipse, enterprise java beans, wpf, n8n, package manager based approaches, microsoft power apps, app builders, supabase,
Which one is ikea?
software is an abstract quantity dependent on nothing but human whim, tech progress, and popularity and cost to build, and changes year over year - you cannot build a ikea like collection or library of components when everything changes year over year like a house or sand and no one agrees on anything
Now if you could pick and choose a few things and have a CRUD app maybe -but most people have reqs that need specific workflowsand that breaks the analogy
To me, AI iteration is biggest revolution of the past few years- ai might allow fuzzy modifications to largely built stacks to work something like an ikea style approach
Yes AI solves this issue in the best way. It's really good at adding features that have already been built many times, but in a way that's customized to your needs and code style.
Physical space itself enforces a set of laws that make any two objects "compatible", regardless of any established interoperability agreements.
However, in software, there is no such constraint. Two randomly chosen software components are, in general, less composable than a chair and a galaxy.
This is the core reason why we have only been able to achieve interoperability in very specific domains. It's not because we're bad at design or planning --- it's because the space of ideas itself is simply so overwhelmingly large that it takes time and incredible coordination to get anything like pre-built IKEA blocks which fit together naturally.
As I get more personal projects under my belt, I believe I'll be able to stand up projects more and more quickly, although it's never perfect. Even though I've been using a similar stack among my side projects for a couple of years now, dependencies get outdated. Sometimes you gotta jump to a new major version. Sometimes you wanna try out the "new way".
I like the idea of building up my own personal stack of tooling, frameworks, and patterns that I use, and could even encourage the use of at $dayjob, but for the reasons outlined above, I agree with the conclusion of the article, which is that an "IKEA of software" doesn't exist currently.
For now I'll keep happily tinkering in my side projects. This article was a good read.
But has any efforts made it far that is universally plug and play? Open source projects had come close. Now those OS projects used by AI coding assistants come close. But no so much plug and play. I think I know why it wasn't happened, and may be can happen.
But I think the idea of abstractions in software engineering, which has guided OOP and even the classes today, is because it was somehow pioneered and may be natural to us to think of the systems that way. Abstractions change from person to person and from teams to teams. Two fleet system components for the same purpose built by two different team will internally behave differently. So universal plug and play for same flows might not work as we think it should be.
Even a low code/no code components, which has a high reusability among completely different projects by different people may introduce overhead that will not work for a said system? because their abstraction of the system isn't the one same as the component was designed? They end up reusing the abstractions of how the system should be around what is already there.
Whats happening now with AI coding assistants, would be the reusability of components software as it should be in this engineering world. It reuses the approaches from any OS project, we can even alternate between the approaches and we get the best out of it (if you know what you're doing) from the different choices and also via our own abstractions of how software should be.
I think we are there, antifragile way of software reusability. We should embrace the choas. A universal metaphorical plug and play for software engineering.
What is missing is the glue, or the business logic, or maybe just the custom frontend you can charge a lot of money for ;)
Using any blogging software and stripe or square or paypal you can setup an online store that comes close to the experience that shopify offers - to the customer. But the backend is nowhere near as good as shopify - you are copy-pasting addresses over to usps or ups, tracking orders with notes attached to stripe payments, and god forbid you should want to automate any transactional emails related to it. Oh, and your system falls apart when you start taking orders via ebay or etsy - since you linked so much process to stripe. So the whole thing devolves into a carefully crafted google sheet.
Which is all to say, i agree with the author - but i feel like we are winning the war, it’s just the battlefront moved from deploying backed services to gluing the pieces together.
"top-to-bottom" needs a better name that doesn't omit the "reverence for the artisans" (aka supply chain nous) that's in IKEA's DNA
https://archive.ph/2020.05.30-154951/https://hbr.org/2013/09...
(We can argue that Toyota or IKEA are both losing out to China in other threads)
Like the author says - fleet-tracking system, a bus-ticketing platform or IoT platform share some basically similar requirements. And this is what those SAP types offer - standardised templated versions of workflows.
But slowly, as they get more and more standardised, they start feeling like calcified systems that the end users start hating. Because they are now forced to work as per the templates.
And then the need for customization. And move beyond IKEA-like standardization.
But I see the allure of the idea.
IKEA things are designed to be simple and cost effective. And it's a vast collection of different things.
At least this is the difference I see.
In another view, standard libraries do a pretty good job.
Just some examples over the years
Odoo, flutter, eclipse, enterprise java beans, wpf, n8n, package manager based approaches, microsoft power apps, app builders, supabase,
Which one is ikea?
software is an abstract quantity dependent on nothing but human whim, tech progress, and popularity and cost to build, and changes year over year - you cannot build a ikea like collection or library of components when everything changes year over year like a house or sand and no one agrees on anything
Now if you could pick and choose a few things and have a CRUD app maybe -but most people have reqs that need specific workflowsand that breaks the analogy
To me, AI iteration is biggest revolution of the past few years- ai might allow fuzzy modifications to largely built stacks to work something like an ikea style approach