“I was only following the requirements” at this point must be the Nurnberg defence of over engineering.
If it quacks like a duck, doesn’t matter what you call it: it was over engineering.
If it quacks like a duck, doesn’t matter what you call it: it was over engineering.
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.
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.
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
> 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.
I don’t care about doorbells or Tulips.
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.
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.