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.
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!
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.
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?
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
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?
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.