It would be over engineered if one could design a system providing similar functionality using less hardware and less software.
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.
Challenge accepted: "Similar functionality" here is the same doorbells that have existed for over a century. Done. :)
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.
Yes, and the person engaged with them is pointing out that more complex solutions exist because someone added other 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.
> Yes, and the person engaged with them is pointing out that more complex solutions exist because someone added other requirements.
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.
> Excel is famously complex because, despite most users only using 20% of the features, no one uses the same 20%
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?
> "The doorbell" is something designed and built by 1 person to meet exactly their own requirements.
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.
I didn't miss it. I have acknowledged the requirements and have challenged them.
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 never claimed I wasn't over-engineering the line of thought, though. :)
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!
Don't overthink it. If you judge the engineering then you look at how the implementation reflects the requirements, not whether the requirements are good.
Over-engineered simply means there is much more in that implementation than the baseline needed to tick off the requirements.
I disagree. IMO this mindset is not how you make good engineering or good products.
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?
Now you're trying to weasel out of this (whstl out?).
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.
I am also trying to be diplomatic and I would like for a more charitable interpretation of my messages.
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.
> "it was in the requirements" is not a "get out of jail card"
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?
You still fail my challenge: design a wireless doorbell that has a user-configurable chime (eg. MP3 file provided by user), in a way that uses less software or less hardware than mine. You couldn't.
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 :-)
And you're still failing the challenge of understanding my point, over and over.
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.
This is was a really unproductive thread to read. As an observer, gotta say I don’t agree with your point. Custom chimes and not having a wire are both extremely reasonable requirements to follow.
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)
> Custom chimes and not having a wire are both extremely reasonable requirements to follow.
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.
We all understand your point: you believe the feature is unnecessary in the first place, without any understanding of my particular situation why I actually need it.
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.
Godwin's law was invoked quickly. It's not very hacker spirit to hear a story of somebody putting together a cool hardware solution to do something they wanted, and then complain that they wanted the wrong thing.
> 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 not really passing judgement on the project itself, or its validity, and I think it's cool. I'm perfectly fine with someone saying "I over-engineered this" or "I hand made this". I do this all the time myself...
I'm just pointing out that "it's in the [my own] requirements" in this case does not really make something "not over engineered".
Is building a bookshelf with adjustable shelves is "over-engineered" because a single fixed plank would hold books just as well? Who gets to be the arbiter on which requirements are the "real" requirements?
It should be considered fair to say that some things are over-engineered in relation to others. This is a matter of (hopefully informed) opinion after all.
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.
It's controversial because your definition of "over-engineered" is different from most other people's understanding of the term. Most people would take it to mean "using more complex systems than needed to achieve a given outcome", while you are defining it more like "using any system at all to achieve an outcome that I consider unnecessary".
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
Of course you can call things over engineered, but seem to want to include questioning the requirements, specifically also those of the example we're talking about.
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?
I agree that requirements need to be kept in check to avoid over engineering. However, I think it's hard to decide for other people far away what their requirements ought to be.
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.
> I agree that requirements need to be kept in check to avoid over engineering
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.
> I'm just pointing out that "it's in the [my own] requirements" in this case does not really make something "not over engineered".
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.
It would be over engineered if one could design a system providing similar functionality using less hardware and less software.
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.
Challenge accepted: "Similar functionality" here is the same doorbells that have existed for over a century. Done. :)
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.
OP stated it requires a user configurable chime. This is not a regular doorbell.
Yes, and the person engaged with them is pointing out that more complex solutions exist because someone added other 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.
> Yes, and the person engaged with them is pointing out that more complex solutions exist because someone added other requirements.
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.
> Excel is famously complex because, despite most users only using 20% of the features, no one uses the same 20%
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
> "The doorbell" is something designed and built by 1 person to meet exactly their own requirements.
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.
You completely missed the part that the chime needs to be user-configurable, ie. play a custom MP3 file.
You don't provide that.
I didn't miss it. I have acknowledged the requirements and have challenged them.
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.
you’ve successfully over-engineered the whimsy and joy out of their original idea
I never claimed I wasn't over-engineering the line of thought, though. :)
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!
Don't overthink it. If you judge the engineering then you look at how the implementation reflects the requirements, not whether the requirements are good.
Over-engineered simply means there is much more in that implementation than the baseline needed to tick off the requirements.
I disagree. IMO this mindset is not how you make good engineering or good products.
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.
> As an engineer (the traditional kind)
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?
> Your whole case rests on the insistence that OP's core requirement is no good
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.
Now you're trying to weasel out of this (whstl out?).
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.
I am also trying to be diplomatic and I would like for a more charitable interpretation of my messages.
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.
> "it was in the requirements" is not a "get out of jail card"
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?
You still fail my challenge: design a wireless doorbell that has a user-configurable chime (eg. MP3 file provided by user), in a way that uses less software or less hardware than mine. You couldn't.
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 :-)
And you're still failing the challenge of understanding my point, over and over.
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.
This is was a really unproductive thread to read. As an observer, gotta say I don’t agree with your point. Custom chimes and not having a wire are both extremely reasonable requirements to follow.
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)
> Custom chimes and not having a wire are both extremely reasonable requirements to follow.
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.
We all understand your point: you believe the feature is unnecessary in the first place, without any understanding of my particular situation why I actually need it.
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.
Godwin's law was invoked quickly. It's not very hacker spirit to hear a story of somebody putting together a cool hardware solution to do something they wanted, and then complain that they wanted the wrong thing.
> 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 not really passing judgement on the project itself, or its validity, and I think it's cool. I'm perfectly fine with someone saying "I over-engineered this" or "I hand made this". I do this all the time myself...
I'm just pointing out that "it's in the [my own] requirements" in this case does not really make something "not over engineered".
Is building a bookshelf with adjustable shelves is "over-engineered" because a single fixed plank would hold books just as well? Who gets to be the arbiter on which requirements are the "real" requirements?
It should be considered fair to say that some things are over-engineered in relation to others. This is a matter of (hopefully informed) opinion after all.
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.
It's controversial because your definition of "over-engineered" is different from most other people's understanding of the term. Most people would take it to mean "using more complex systems than needed to achieve a given outcome", while you are defining it more like "using any system at all to achieve an outcome that I consider unnecessary".
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 not saying every product has to be the absolute minimum, that's an absurdist interpretation of what I mean.
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.
Where would you draw the line for a sufficiently simple implementation of sufficiently simple requirements? A door knocker? A door?
I don't think there should be a line.
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.
Of course you can call things over engineered, but seem to want to include questioning the requirements, specifically also those of the example we're talking about.
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. :)
I am just saying over and over that the over-engineering part itself can come from a "requirement", which seems to be the contentious position here.
Some other people mentioned the doorbell project was over-engineering and I just agreed with them.
I agree that requirements need to be kept in check to avoid over engineering. However, I think it's hard to decide for other people far away what their requirements ought to be.
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.
> I agree that requirements need to be kept in check to avoid over engineering
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.
> I'm just pointing out that "it's in the [my own] requirements" in this case does not really make something "not over engineered".
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.