Nice to see this again. Previous submissions, 4, 5, and 6 years ago, generated very little discussion. It will be interesting to see if this fares any better. Personally, I found it more entertaining than enlightening, more amusing than analytical.
Is the bigger problem. When I hear "instead", I think, "oh good, we can delete a bunch of stuff we don't need anymore", but when I hear "also", I think, "oh crap, not only do we need to add stuff, we need to make the existing stuff more flexible".
This happens all the time in all engineering projects. Generally, if the requirements change that drastically in the middle of the project then either the initial requirements were terrible or the requested change is just a bad idea.
Many an engineering project has been sabotaged because someone tried to force a bad change into the middle. I could go on all day just with examples from the Pentagon.
The hardest thing in software is predicting the dimensions of extensibility that are important. This ability usually only comes on the third or fourth try building a similarly-classed, similarly architected system. Making all the dimensions extensible is generally a recipe for disaster.
I have a somewhat formal process for this, which I teach to developers I'm mentoring:
First, you build a feature for the requirements you know you have, with support (possibly stubs) for the requirements you know you're going to have in the next version.
When it's time to implement the second version, you refactor as-needed to support the new requirements you have, with support for the requirements you know you're going to have in the third version.
Do the same refactoring and support approach when you implement the third version.
By the time you get to the fourth version, you'll generally find that you've already built all of the extensibility you're going to need, and you'll just be using that rather than refactoring anything.
I like this process because minimal effort is put into implementing any requirements you don't need yet, while taking into account future requirements you know about so that you don't build something that makes the future requirements very difficult to implement.
The real question is, did the King have him beheaded because he failed to use a BreakfastFactory pattern, ensuring that the order for the breakfast can be decoupled from the cooking of the food?
Arguments (or stories implying arguments) of the form "There exist bad X, therefore X is bad," are never terribly compelling. Yes there is such a thing as bad object oriented design, just as there is such a thing as bad functional programming, bad unit tests, bad science, bad music, and bad bacon. The existence of badness in any given field does not imply that the whole field is bad.
Object oriented analysis and design, done well, is not bad: it is good. It's not wrong to design a class, even a hierarchy of classes perhaps, for a toaster program. Whether doing so is helpful or harmful really does depend on the functionality and complexity of the toaster and the skill of the class designer.
So: sure, bad software design is bad. Thanks for pointing that out. But if the implication is that all (or most or "usual") object oriented design is necessarily bloated, overworked, and excessively forward-looking, then no: only when it, like overcooked bacon, is done badly.
A pure functional toaster would work one of two ways:
1) It would just be a solid box with no openings. Inside would be full of wondrous magic, but interacting with the outside world involves side-effects so interaction would not be allowed.
2) It would have a glass panel on the side, which you'd hold your untoasted bread against. A slice of toasted bread would pop out of the top. You'd never know where it came from, but you'd be happy that your original slice hasn't been modified.
Only for a moment. An extensible claw would fly out, grab the untoasted bread from your hand and fling it into the garbage can, after a brief but unpredicatable interval.
The king is obviously from a more primitive time. In the future everyone will want a general-purpose cooking machine that can make toast, scrambled eggs and bacon in parallel.
All these single-purpose kitchen machines take up so much space.
A general-purpose cooking machine that can do all these things in parallel is nearly as large as three individual machines, assuming you are not sacrificing performance for size. It is also more complicated than three individual machines and causes greater headaches if one of the functions breaks.
Weirdly enough, "improve this toaster somehow" is one of the interview exercises my company uses the most. We give candidates 15-30 minutes to sketch a solution collaboratively with the interviewer. Answers are a great indicator (I think) of whether a designer ir engineer is user-focused and the ensuing discussion gives a lot of insight into their values and thought processes.
This made a big impression on me when I read it. I think it helped me. When I find myself yielding to a certain kind of programmer's temptation, I will mutter, "four-bit microcontroller..."
28 comments
[ 3.1 ms ] story [ 68.6 ms ] threadKing: "Make me a toaster."
Software developer: makes toaster
King: "Okay, that's great, but could you also make it scramble eggs? It should just be a small change, right?"
Software developer: adds egg scrambling module
King: "Actually, could the eggs be soft boiled instead?"
etc.
In other words, OO and other programming abstractions arose precisely because we actually do need to deal with changing requirements, all the time.
...But I don't think it's great satire, for the reasons you point out.
A phrase that so very often tests the self control, patience and will to live of software developers around the world.
Is the bigger problem. When I hear "instead", I think, "oh good, we can delete a bunch of stuff we don't need anymore", but when I hear "also", I think, "oh crap, not only do we need to add stuff, we need to make the existing stuff more flexible".
My answer to that question is usually. "Yes, as long as you're willing to pay for it."
I'm not a consultant. "Payment" comes in many flavors.
Many an engineering project has been sabotaged because someone tried to force a bad change into the middle. I could go on all day just with examples from the Pentagon.
First, you build a feature for the requirements you know you have, with support (possibly stubs) for the requirements you know you're going to have in the next version.
When it's time to implement the second version, you refactor as-needed to support the new requirements you have, with support for the requirements you know you're going to have in the third version.
Do the same refactoring and support approach when you implement the third version.
By the time you get to the fourth version, you'll generally find that you've already built all of the extensibility you're going to need, and you'll just be using that rather than refactoring anything.
I like this process because minimal effort is put into implementing any requirements you don't need yet, while taking into account future requirements you know about so that you don't build something that makes the future requirements very difficult to implement.
Object oriented analysis and design, done well, is not bad: it is good. It's not wrong to design a class, even a hierarchy of classes perhaps, for a toaster program. Whether doing so is helpful or harmful really does depend on the functionality and complexity of the toaster and the skill of the class designer.
So: sure, bad software design is bad. Thanks for pointing that out. But if the implication is that all (or most or "usual") object oriented design is necessarily bloated, overworked, and excessively forward-looking, then no: only when it, like overcooked bacon, is done badly.
1) It would just be a solid box with no openings. Inside would be full of wondrous magic, but interacting with the outside world involves side-effects so interaction would not be allowed.
2) It would have a glass panel on the side, which you'd hold your untoasted bread against. A slice of toasted bread would pop out of the top. You'd never know where it came from, but you'd be happy that your original slice hasn't been modified.
All these single-purpose kitchen machines take up so much space.
Spoiler: there are problems with many toaster ovens.
Does anyone want any toast? - https://www.youtube.com/watch?v=LRq_SAuQDec