The Object-Oriented Toaster (1997) | Hacker News Reader

The Object-Oriented Toaster (1997)

danielsen.com

49 pointsfludlight28 comments

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.

This is funny, but I think it misstates the real problem. This is what would really happen:

King: "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.

I enjoyed reading it - it's amusing and some of it resonates with my experiences.

...But I don't think it's great satire, for the reasons you point out.

>"Actually, could . . . instead?"

A phrase that so very often tests the self control, patience and will to live of software developers around the world.

> "Actually, could . . . also?"

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".

Eh.

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.

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.

But the EE can start over and still finish earlier - and deliver toast in the interim.

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?

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.

Usually see this titled 'Electrical Engineering vs. Computer Science' http://web.cs.wpi.edu/~gogo/humor/hum_toast.html http://philip.greenspun.com/humor/eecs-difference-explained

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.

Do you know about John Siracusa and toasters (...toaster ovens, actually)? He has literally spent hours talking about toaster (...ovens) on various podcasts. https://www.caseyliss.com/2015/9/10/siracusa-on-toasters.

Spoiler: there are problems with many toaster ovens.

That software developer sounds suspiciously like a product manager in need of some push back from lazy software developers.

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.

wow, its just a joke lighten up

S'alright a pure functional toaster just spits out yer bread untoasted.

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.

Keep going, I want to hear how monads get mapped into the world of toast. :-)

You can think of monads as abstractions that may or may not return toasted objects.

So maybe toast?

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.

It could have been even worse. At least it didn't have ARTIFICIAL INTELLIGENCE SYSTEM K177.

Does anyone want any toast? - https://www.youtube.com/watch?v=LRq_SAuQDec

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.

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..."

I'm surprised I haven't read this before. Very entertaining.

Reply on news.ycombinator.com