Edit: there are very, very few products on the market designed as simply as this, just an R/F signal triggering local playback. I think the only commercial doorbells designed like this I found were an out-of-stock product, and a UK device designed for 230V that would have required a bulky adapter to work for me in the US.

My light switches are similarly complicated.

I know a guy who lives is a 1700's-era house. His is a bell, a pulley, and a string.

The problem is they've probably gone to the wrong house before and met an owner who got defensive.

As for availability, they are certainly very obtainable where I am in UK. Shops and Amazon etc have them.

- All consumers own smartphones and like using them

- Consumers have no idea how their home networking works

- Consumers could not move a file from their computer to an SD card (or something similar)

So, everything is done by the app: you install the app, the smart device broadcasts a wifi network. This allows you to use your phone to give the smart device your wifi password. Then the remote servers handle everything else.

There's nothing in between. You're either an actual engineer, as mrb describes, or you're just beholden to cloud services that are terrible and also are guaranteed to disappear in 0-3 years.

But my implementation of these requirements is absolutely not over engineered. I argue it is the simplest and most reliable it could be done.

I challenge you to design a wireless doorbell that has a user-configurable chime, in a way that uses less software or less hardware than mine. You couldn't.

In fact, if you did market research like me you would find that 99% of similar products have vastly more complex hardware or software or services being them. They break when there is no Internet. Some work without Internet but don't work when the local Wi-Fi is non functional. They don't immediately get back online after a power outage. They need regular software updates during which the chime can't play. These are over engineered things. Not my product, because mine has none of this complexity or faults.

If the requirements and constraints come from you, then saying "those are the requirements" doesn't settle anything. And is the same excuse people use for the over-engineered solutions you don't seem to like.

It is over-engineering compared to a regular doorbell, period.

You don't provide that.

What I am stating is that "it was in the requirements" is not a "get out of jail card" when someone says it's over-engineered.

All I'm saying is that it's a very comfortable position to abstract away personal responsibility and say "I'm not over-engineering, that's what X wants", but that's exactly how we get the over-engineered Linux-plus-wi-fi doorbells.

Then I want you to justify why commercial products offering this feature have 10-100 times more code or 10 times more complex hardware just to do what my doorbell does :-)

The person who gave an opinion about whether this is overengineered or not was Lukeify, not me:

> You are super-sensitive to over-engineering, so you over-engineered your requirements and ultimately your end product, just in a different methodology and framework.

It's still over-engineering to a lot of people, including lukeify, regardless of there existing something worse, regardless of any "it was the requirements" defence.

Over-engineering something is fine. Especially a personal project.

Just own it.

What if the default chime triggers some PTSD? (Probably doesn’t, but it could happen!) What if the landlord doesn’t want you to drill a hole through the side of your house and it doesn’t come with a doorbell?

The solution isn’t “over engineered” it’s just “engineered” (not an off the shelf product)

I never said otherwise?

Perhaps it was unproductive because you’re assuming I’m making a point while I’m not?

My point was entirely that other people can call this “over engineered” due to feature creep.

The person who called it over engineered in the first place wasn’t me.

I appreciate that you and other people seem to want to discuss doorbells, and someone else seems to want to discuss christmas lights, but I am not really interested in that.

I am arguing a general point (“feature creep can lead to overengineering”), not this specific product.

Regardless, this is irrelevant to the point of this entire thread, which is that it's possible to design a device, as I did, that is vastly simpler than commercial doorbells allowing user-customizable chimes.

Here, someone else explained. Maybe you can understand better if it comes from someone else: https://news.ycombinator.com/item?id=49508403

I'm perfectly fine with people having fun or over-engineering stuff, I'm just pointing out that it's still over-engineered in the end. Which is 100% fine!

How do you define objectively as an engineer if "play MP3" is too much? A doorbell is a sound outputting device only, being able to select the sound seems like a reasonable extension. Is a digital doorbell overengineered when analog electric ones worked just fine for almost 2 centuries? Or were these overengineered when mechanical doorbells worked for many more centuries before? What if I attach a light to the doorbell, is that over engineering?

Or are you just fighting to save face after missing the point completely and making that tasteless Nurnberg trial parallel?

Over-engineered simply means there is much more in that implementation than the baseline needed to tick off the requirements.

As an engineer (the traditional kind), I don't really appreciate nor can I afford the "not my problem" attitude of doing engineering in a vacuum, because in the end it's my responsibility.

Isn't everybody? Your whole case rests on the insistence that OP's core requirement is no good. Not for any objective engineering reasons, just because you think so.

I have a simple question that any engineer can answer in a heartbeat. Is a Christmas tree light installation with a bunch of series connected incandescent lights (I'm talking literally one of those classic Christmas lights set with absolutely no extra components or complexity beyond wires, bulbs, and plug) over engineered? Could you do it with even less engineering?

I never said it wasn't good.

I just said it led to over-engineering a doorbell.

"Good" or "bad" are words you're putting in my mouth.

I was trying to be diplomatic and use "good/bad" as shorthand for "should be part of a well engineered (not over/under) product or not". You don't like it, then let me use what you actually said: engineers who implement all the requirements given to them are like the Nazi soldiers who executed the people they were ordered to execute. Neither good nor bad, just over executing, right?

I asked you a question because it was an easy way to apply your logic on something concrete, so you can see that if it fails on something so simple, maybe it's not actually useful at all. You pretended not to see it like a fine engineer with responsibilities. Tripped on a Christmas light.

My whole point is that "something being in the requirements" is not a shield against something being considered "over engineering" by others. There's nothing more to it.

And I said exactly the opposite of that.

Doing bad things is bad, despite following orders.

Over-engineering is over-engineering, despite following requirements.

Maybe “I want a configurable chime” is just a less popular requirement than “I want to be notified on my phone even if I'm not at home.”

Also, Excel is famously complex because, despite most users only using 20% of the features, no one uses the same 20%, so if you want cover close to 100% of the market, you need to ship features that are useless to most of your users.

Precisely.

The Wi-Fi and Linux solution that was called over-engineered just happened to have different requirements. Engineering is a collaboration, not blindly solving very specific problems.

I think you're comparing 2 very different scenarios here.

Excel is solution engineered to meet every requirement under the sun, for every possible user.

"The doorbell" is something designed and built by 1 person to meet exactly their own requirements.

whstl (the other commenter) insists that he is better suited than the benefiter and builder of that doorbell to decide what is a good requirement and he's willing to make tasteless jokes comparing anyone who doesn't agree with his assessments to Nazis on trial at Nurnberg [1]. You'll notice that whstl didn't even ask why the requirement exists in the first place, just concluded it's wrong (it's something they teach you on day 1 of engineering school, build whatever you want, better if you don't ask questions where the answer might inconvenience you).

When you have a requirement would you take the word of someone on the internet just saying it's not a valid one?

[1] https://news.ycombinator.com/item?id=49506886

Nothing wrong with that.

Also nothing wrong with people going to great lengths to build an Excel replacement that fits their exact requirements like glove, by ignoring 99.9% of what makes Excel … excel.

The issue is calling Excel over engineered for catering to everyone else:

> You would be surprised that 99% of the solutions out there are complete over engineered stacks that depend on wifi devices, Internet access, connecting to various cloud services...

Even if all some people wanted was a custom sound on their doorbells, I bet many of those people will want to transfer the sound using a smartphone rather than an SD card they can't modify with a computer many don't own. And, given that capability, even more people will want to be notified of a ring on their phones, and then why not when they're outside (maybe on the backyard) away from the LAN, and then why not while they're at work, and so on and so forth.

The “over engineered” solutions are actually engineered to cater to everyone else, that is all.

And to make whstl's point: I find it much easier to justify internet and cloud to support a doorbell that's genuinely more useful (rings remotely) than SD cards and custom hardware to justify something as … frivolous as changing the bell's sound.

PS: I just spent $70 modding a $20 Casio watch. I loved every second of it.

Is a coffee machine with 1000 parts over engineered? For home use yes. For use on the ISS probably not. Context is important, take something out of context and you’ll confidently give the wrong answer.

Anything can be considered over engineered if we just ignore the requirements of the user/builder. Copy from phone? Over engineered with wireless. Copy over SD? Over engineered with a controller. Have a door bell at all? Over engineered with wires.

Start with the goal of the device. Do you want a doorbell with a ring you can choose? SD is probably a lower complexity choice and can’t really go much lower. Do you want a doorbell with internet? Add basic internet connectivity. Unless you do it in a convoluted fashion, with more parts and complexity than needed to achieve that, it's not over engineering.

> And to make whstl's point: I find it much easier to justify internet

I read the opposite. whstl made 2 points for as long as I could be bothered to read his comments: that engineers who implement all the requirements are like Nazi soldiers committing genocide, and that additional features on a doorbell amount to over engineering which is exactly the opposite of what you say.

If you don't need internet, why add it just on a "might as well" basis? The feature creep can go on forever like that. Add a 2-way intercom, video camera with IR and floodlight, some AI recognition stuff, local and cloud backed storage, etc. Now you also created a headache to maintain the software or guarantee it will be in a botnet soon.

Always start with what you need, what’s the goal of the device, and how can you implement that in the most reasonably straight forward fashion as possible. Just so you don’t end up with a doorbell that runs Vmware because "why not".

I can't be sure about whstl, but that's my only point.

And, really, nothing against going to great expense/effort to build exactly what one wants. In fact, I love doing just that.

> check out my hand-embroidered curtains, it's got exactly the flower pattern I wanted

> yeah well you shouldn't want flowers on your curtains, just buy plain white ones from the store

I'm just pointing out that "it's in the [my own] requirements" in this case does not really make something "not over engineered".

Also opinions will change after time, or after analyzing the problem space better.

GP also said that lots of product in the market are over-engineered, so I don't see why my view (that this is an over-engineered doorbell) is controversial at all.

The former definition is somewhat objective in that it can be tested and proven, while the latter definition is entirely subjective and sort of meaningless. I could just as well state that any doorbell is over-engineered since you can just knock.

> GP: The minimum of 5+x^2 is closer to 5.5 than 10

> You: If you were minimizing 3+x^2 you could get an even lower value

I am saying that people can call something "overengineered" and "it was the requirement" is not a defence.

Maybe what I mean is: Feature creep does contribute to overengineering. That's not controversial in the engineering community at all.

> I am saying that people can call something "overengineered" and "it was the requirement" is not a defence.

Okay, so you're not saying to reject all above-minimum features, but then there seems to be no objective criteria, so who is deciding which ones to reject? Why is it not the customer?

And it's not a does-nothing feature either, it has a meaningful impact on the user.

> Maybe what I mean is: Feature creep does contribute to overengineering. That's not controversial in the engineering community at all.

A requirement from the start, the baseline of the product pitch, is the opposite of feature creep.

But it helps to have somewhat objective criteria, like whether it was feature creep. And this was not feature creep. And custom sound for something like this is a desirable feature for the average person; you can look at the massive ringtone business in the 00s to prove that.

> And custom sound for something like this is a desirable feature for the average person; you can look at the massive ringtone business in the 00s to prove that.

And every AI startup should send a monthly Tulip to every user. The Tulip craze of the 1630s proves that.

People like to customize sounds. Lots and lots of people.

> It is also the right of anyone to call something feature creep, using their own criteria.

I was listening to your potential argument for "over-engineered", but "feature creep" is pretty objective. This was not feature creep. OP wanted a specific feature from the start and even went out of their way to exclude lots of features.

Tulips?

> I was listening to your potential argument for "over-engineered"

It wasn't me who made such argument.

Since you brought up tulips, you should know very well they were not paying small amounts and the problems all came from people that were not directly enjoying them. Your analogy between them and ringtone enjoyers is hopelessly broken.

> It wasn't me who made such argument.

First off, you did. You said "If it quacks like a duck, doesn’t matter what you call it: it was over engineering." and as a followup you said "Challenge accepted: "Similar functionality" here is the same doorbells that have existed for over a century. Done. :)". You started off actually participating in the discussion about whether the doorbell was over-engineered, and only later started trying to be so abstract and unfalsifiable.

Second off, even if you hadn't written those comments and you had actually made yourself impartial about the doorbell itself, I would still say the same thing to you. Read this again: I was listening to your potential argument for "over-engineered", but "feature creep" is pretty objective. This was not feature creep. OP wanted a specific feature from the start and even went out of their way to exclude lots of features.

My comment there doesn't even say you were calling it over-engineering. It says you were making arguments about it, which you were. You were defending the people calling things over-engineering by bringing up feature creep. So I pointed out feature creep is even weaker and doesn't apply here.

Anyway, I could maybe think you honestly thought the second half of my post didn't apply to you. But your "Tulips?" response to the first half makes it clear you're being disingenuous and dodging. Prove me wrong? But I'm not holding my breath.

You point that out without providing any context or criteria. So you're just pointing out your personal opinion, nothing resembling fact. In this case everything is over engineered. The doorbell is overengineered before even discussing mp3.

But it should be considered fair to say that some things are over-engineered in relation to others.

It should also be considered ok to call things over-engineered. OP himself did.

Once you start that, you also need to stop somewhere. For example, we could even question the need for a door in the first place. Not saying that we should, but if you want to take over defining other people's requirements, you're putting this on yourself.

So if you don't want somebody else to call you out for over engineering somebody else's requirements, where do you stop?

It's not an enviable position to be in. :)

Some other people mentioned the doorbell project was over-engineering and I just agreed with them.

So I don't agree that you can call mrb's basic wireless doorbell "overengineered" for requirements reasons alone without opening yourself up to the same scrutiny that you're applying to him.

Then we are in agreement!

The person who originally called it "overengineered" wasn't me, it was another user.

I did joke that an electric doorbel "does a similar job" but that was to demonstrate that "similar" is also a judgement call.

I am just saying that lukeify or anyone can call it overengineered from their point of view, similar to how GP called commercial products overengineered.

Interesting context you live in. Here in east europe, 90% of devices you find on eshops are cheap chinese buttons with AAA batteries, that emit signal and another reciever device that plays sound. The sound is not customizable, but it is super cheap stuff.

I would have to go out of my way, to find cloud connected doorbell.

This is EXACTLY the problem! Try finding one that I can customize with my own chime and you will only find expensive, unreliable, over engineered stuff.

Or buy 5, and decide which tone you like most.

But honestly, even if you have nothing, if you know a bit what you are doing with IoT with HomeAssistant if you buy the right hardware (i.e. verified as working by others, e.g. the Sonoff ones typically) it's at most an afternoon of tinkering for a setup that will reliably work for years.

Now we're in "under-engineering" territory. Also not good.

Then I guess 3d print a casing that just puts the ZigBee button on top of the integrated button?

https://en.wikipedia.org/wiki/Satisficing

Over engineering is about the solution, not the requirement:

> I wanted something that lets me play a custom bell

No because similar commercial products were either out of stock or not compatible with my AC voltage.

Granted maybe your requirements are ridiculous. But I also had cases where I DIYed a solution because the commercially available solutions all either didn't fulfil the requirements and/or had anti-features that ruled out their use. I haven't had any regret so far with these solutions, with some of these being active for over a decade.

There may be over engineering, but replacing a bought solution that needs to connect to the internet and someone else's computer to ring a bell with a simple 433MHz sender and a MP4-player module isn't that. Do you know what is required for a device to even connect to a WiFi? That alone is more complex than the whole system the user built here.

Simple systems have the advantage that there are less moving parts. Less moving parts means less chance of failure. That is a trade-off an engineer will sometimes take even if it means building a new thing, sometimes something with more moving parts is needed and that is okay as well.

Maybe your requirement is to have a doorbell that does work when the internet is out. Who knows? OP might live in a place where this happens more often. Or they might not and like the idea to never again have to think about their doorbell-manufacturers cloud and the latests exploits targeting that IoT product. There are many reasons why simple can be the right choice and any true engineer would say: "depends" instead of "so what".

You are correct in general, but I think "so what?" was an adequate response (even though I don't agree with it) in this case that actually furthered the discussion as can be seen from your long reply.

We don't always need LLM-like, long comments. Sometimes "so what?" can be intriguing enough.

If you click on the little resorts/hotels/towns around the area, there are many pictures and videos of steam rising of this little river. It's obvious the area is well frequented by tourists. Not as remote as I thought it would be.

Nor the law banning nuclear for electricity generation.

Nor the attempt this year to reverse that law which got defeated.

Ireland appears to not want nuclear ;)

China seems to do 7 years _build time_ at ~$3bn/GW. So you're probably looking at at least a decade project start to end. Also, they're primarily using a reactor that isn't licensed in Europe and won't be anytime soon. The only Chinese plant using a European-licensed reactor type (EPR) took a decade to build (still faster than European builds of the same reactor, but not what you'd call quick).

Sure enough France exports up to about 4GW to the UK, and the UK exports up to about 1GW to Ireland. Right now, it being the middle of the night here, France sends us about 2.5GW and we sent Ireland about 500 MW.

Electricity being fungible by nature it doesn't really mean anything to say that's French electricity when it reaches Ireland, it could just as easily be British nuclear, or wind power from a Scottish wind farm, or any number of sources or any mix.

It's also a two-way flow; while UK<>Ireland transmission tends to net out to UK->Ireland, it's fairly variable; to a large extent whichever side currently has too much wind is the donor.

Current government plans don't seem to take this into account. 40GW of wind power doesn't seem like "basically enough" when you're doing 10GW exports.

They did at least ban "rebidding" where you get permission to build a wind farm, but you think the price you agreed to isn't what you'd prefer so you just bid again next time like nothing happened. Some of the projects which low balled are now stuck, either build it as promised and collect a smaller profit than you'd hoped for or fuck off, no second chances

The HVDC line to France will help with this; it will less frequently be very windy in Ireland and the UK _and_ France.

Longer term, though, everywhere is going to need a lot more storage (and possibly smart variable demand; remains to be seen how practical that is at scale.)

But it is in itself fairly non-trivial; HVDC cables that long are difficult.

In 20 years time the same response will be spouted, it will make you wish you did something 20 years before when it was originally discussed.

I'm still not versed enough on the environmental impacts of batteries. There is a lot of battery tech advancements in the past decade.

These are two different use cases. I do not think anyone in their right mind is using Zelle to send money to a party they do not fully trust.

My best guess at this point is the 2025 LG TVs have some different HDMI ARC something something compared to the 2019 it was plugged into before.

But also my point is that there's no way a human with 3 kids and job could ever know... it either starts working or I get a PlayStation or a different PC or whatever.

Or just tell my kids, "Hey, Death Stranding works on your Mac now, so shut the fuck up until you finish that whole game." ¯\_(ಠ_ಠ)_/¯

1963: Operation Empty-the-purse ("vide-gousset")

It was also by warship that De Gaulle planned to conduct "Operation Empty-the-purse" in 1963, the code name for the repatriation of French gold deposited at Fort Knox in the United States (1). More than 1,150 tons—the result of converting French dollars into gold, a decision made by De Gaulle in response to the lax monetary policy of the United States—were being used to finance a growing trade deficit through the printing of money.

Valéry Giscard d'Estaing, then Minister of Finance, recounts (2): "De Gaulle was getting impatient and asked me at every meeting: 'So, has that gold finally come back?' One day, he told me: 'We need to move much faster: we're going to send the navy cruiser 'Colbert' which will bring back all the gold that's still there.'" “I told him that if we did that, we would alienate American public opinion forever.” Ultimately, De Gaulle abandoned the Colbert plan, and French gold returned from the United States in small quantities. Not for very long, it's true. The events of May 1968 and the ensuing monetary crisis depleted the reserves, which fell from 4,650 tons to 3,150 – 1,500 tons had crossed the Atlantic again to defend the franc, which De Gaulle refused to devalue.

> Ultimately, De Gaulle abandoned the Colbert plan, and French gold returned from the United States in small quantities.

So I think the story about the warship got twisted from a plan or threat to "it actually happened". Doing it in small quantities over a few years was the right way, indeed. Looking back it seems like it didn't make many waves in the news at the time, so Giscard was absolutely right.

Want to bet 100 MB? 1 GB? Is it unthinkable?

20 years ago, a 49 MB home page was unthinkable.

I think there'll continue to be growth in page sizes, but then maybe we'll consider efficiency, or the NYTimes shuts down and the 20MB page will be the liquidators selling the domain. Maybe we don't even use domains by then as everything is on an app.