Hacker News Reader

Comment by agentultra | Hacker News Reader

"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."

-- E.W. Djikstra

If you want simplicity you have to do hard work. It doesn't come by simply removing libraries. Some of that may be incidental complexity and you will get better performance from it. However the core problems themselves, the essential complexity of the problem: to make a solution that solves it in a simple way requires thinking. And if there's one thing I've learned in my career: people hate thinking.

Businesses tend to prefer quick solutions and will pay whatever cost to have it now rather than later. Elegant, simple solutions require time and thought. That is expensive and slow. Since businesses pay our salaries we do what we can and we slap on a library or use a framework and move on.

View on HN

The road to hell is paved with products that pursued simplicity but ultimately couldn't afford it.

* Just Doesn't Work

* Your simplicity becomes my complexity (fussy compatibility, batching creates latency, etc)

* "One-button" interfaces where you have to learn a morse-code dialect and timing to access the necessary features

* Bonus points: the software is laggy and the one button is mechanically unreliable, compounding the difficulty of getting the timing correct

* Useless error messages that make simple problems complex

* Similar: Necessary complexity (e.g. radio reception, authentication, updates) hidden behind a featureless spinning wheel for maximum time wasting when you can't tell what the holdup is

> Your simplicity becomes my complexity (fussy compatibility, batching creates latency, etc)

Forth is simple. (It is not that hard to write a simple Forth system that implements the language in a workable fashion.)

Python is simple. (It is a good choice for a first programming language, and plenty of people use it to rough out ideas because it allows them to ignore some kinds of resource management details and comes with a large standard library.)

Equivocating on 'simple' is a neat trick if you can pull it off.

Python is easy, not simple. Lisp is simple.

> Lisp is simple.

Look at the Common Lisp FORMAT function and say that again.

[R5RS][1] is simple.

To get any work done with it, though, you need to write your own Python.

[1]: https://conservatory.scheme.org/schemers/Documents/Standards...

That is admittedly a bit of an abomination (very powerful though) but the language itself is very simple. It just allows the creation of DSLs which is what format really is.

Not sure you're using simple in the same way other people use that word :)

I believe GP is using it in the literal etymologically correct way in the vein of Rich Hickey: https://youtu.be/LKtk3HCgTa8?feature=shared

Pedantically, Common Lisp being a Lisp-2 vs a Lisp-1 arguably makes it a duplex vs a simplex…

I don't think your examples feel like the simple options to me. For example:

Batching should solve a specific problem, it's not really complicated to implement but without a need adds unnecessary complexity to the system. Simplicity in this case would be no batching and just handling the inputs as they come.

One-button interfaces while minimalist are not simple, you've already covered why they're complicated. They can be simple though, if used correctly, but you're intentionally over-complicating to make a point. Even no button interfaces with gestures can be simple an generally intuitive.

But you're correct that my simplicity may be your nightmare. I use DWM because I don't need or want the complexity of a full desktop environment. Most of what I do use the same vim keybindings, and runs in the terminal. The settings for all of those are in a git repository and I install a new machine or VM with a single line that I've memorized at this point.

To you that may seem like a brittle hell, to me it's the simplest most stable system I can design.

> "One-button" interfaces where you have to learn a morse-code dialect and timing to access the necessary features

Flashlight enthusiasts, I'm looking at you. Doubly so when there isn't a way to know the current state without already knowing the current state.

I feel attacked! :)

I mean, it's a hard problem - for many reasons you only have one button, with no way to display information. And you have to cram possibly many functions into that one button.

It's a really interesting exercise in UI, and there are benefits to different approaches. I actually like comparing the different ways manufacturers have chosen to solve this.

I really want more Bluetooth support in flashlights. Not only would you always know where they were, and their state of charge, but if you leave your bag in a corner somewhere at a location, it could ping you if it gets moved or opened but isn't within a few feet.

BLE mesh means you could link them in groups for lighting large areas that don't have power yet.

You'd never have a mode you didn't like, just turn of the dang flash mode or map it to a long press. The dim mode could be as dim as you wanted it, down to sub milliamp for when you're working in a dark theater and need to read your notes.

You could set it to turn on when unplugged for an emergency light, glow all the time faintly to find it....

I wonder if there's a market for boutique handmade one off lights... Making a few a year might be fun but I sure wouldn't want to start my own production scale anything.

Although these would really be at their best if they were mass produced and cheap enough to have several.

That's an interesting idea. I'm not very versed in the flashlight world, so I don't know if it exists, but I at least haven't heard of a "pocket" flashlight that has bluetooth support.

Olight does make these "bulbs" that have Bluetooth support, you can configure color settings there through an app.

As far a market, there probably is if you're good. There are a bunch of people who collect all manner of flashlights, and boutique one-off things are usually a great thing.

Adding bluetooth to a flashlight probably adds at least 2 dollars to the BOM, cpu upgrade and bluetooth module (for reference one of the cheapest might be an espressif chip in the $1.5 range, but they don’t do low energy very well when bluetooth is involved). So it’ll cost roughly $18 more than the next flashlight. So maybe? I’ve worked on BLE mesh, and it’s enough of a pain at the moment that I wouldn’t be willing to implement this on something as cheap as a flashlight, but then again I was just poking around and found flashlights easily selling for over $100. so there may be a market for this.

Unless it got popular enough that you were making bazillions. It really shouldn't need to cost much more than a normal flashlight plus the $2 Bluetooth SOC. An existing manufacturer would probably charge a premium but a new company could be like "2 buck more and you get Bluetooth".

Actually seems like something Pine64 would do really well.

(I could also be talking out my ass here though, I know nothing about business, and Bluetooth anything might attract technophobia and make some people actually less interested).

>I mean, it's a hard problem - for many reasons you only have one button, with no way to display information.

Yes, there is a way to display information: put a screen on the device. My bicycle headlight has this: https://www.niterider.com/products/6780-lumina-oled-1200-boo...

Of course, this costs more. The OLED screen version of this headlight costs significantly more than the plain one-button version.

> And to make matters worse: complexity sells better

Yes!

The article claims people think they want simplicity, but aren't willing to sacrifice anything to get it. But the reality is much worse.

People, at least business people (people making decisions, not end users), hate and loathe simplicity, and love complexity. Or, if not complexity per se, all the benefits it brings. Esp. bragging rights.

You have to be able to boast the number of engineers working on the project, the millions spent... and even the bad performance!

Bad performance is proof of the difficulty of the problem. If something actually works, it means it wasn't that hard to begin with.

> The article claims people think they want simplicity, but aren't willing to sacrifice anything to get it.

I live CNN lite: https://lite.cnn.com

I guess I am weird but the way websites are designed confuses the crap out of my brain.

> I live CNN lite: https://lite.cnn.com

Such a refreshing site to see. It is like early 2000s internet before the introduction of the dynamic web.

https://www.w3schools.com/asp/asp_ajax_intro.asp#:~:text=AJA....

oh gosh this is amazing

There's also https://text.npr.org/

Wow what the hell! How am I just now seeing these for the first time? They're so fast, simple, clean, and to the point.

Every news outlet and blog should have something like this. Seems relatively quick and easy to put together compared to their main sites, and I'm sure tons of people will use & appreciate it.

There was some discussion of text-based news sites on HN a while back. You may enjoy the coverage.

https://news.ycombinator.com/item?id=35313232

> If something actually works, it means it wasn't that hard to begin with.

This one affects a huge proportion of modern software developers too, and has two close relatives where we wildly over reward those that fix things heroically at 3am while under appreciating those that prevented it breaking at all, or my favourite "what I do is hard, important and valuable, what you do is trivial, so why don't you just give it away?"

Making things that appear to work first time has been one of the defining repeated errors of my career.

feynman wrote about this. He famously, already having figured out the first 2 digits of a locked filing cabinet over the course of months, sat down and read a magazine for a length if time before “cracking” the lock when someone lost the key.

Said he learned from a locksmith that people hate it when he makes it look easy.

For some reason people value effort over expertise.

Not only that, but horrible maintainability is also proof of difficulty. If something requires multiple engineers to babysit, 24-7, then certainly that's not something inherent in the design, it's inherent in the problem.

Having been involved in some of those enterprise product evaluation decisions, that isn't how it really works. What they do is gather and prioritize a huge number of requirements from various internal stakeholders (some of which have the power to block the project if they don't like where it's going). And many of those requirements really are "must haves" to run the business, or even achieve legal compliance. If a product doesn't meet the key functional requirements then it's a non-starter regardless of usability or simplicity.

A fair few nice-to-haves get hidden amongst the must-have lists too, just to make matters worse. This is how you end up with a product that has features literally no one ends up making much use of.

Also if someone particularly wants a piece of software for their role they may try sell it to the rest of the business with ideas of what it can do more generally. This is why kitchen sink products sometimes do well (but ultimately make no one happy as they don't do anything perfectly while trying to do everything well enough to claim it is supported).

If some employees are unhappy that is an acceptable outcome as long as the work gets done. We can't afford to make everyone happy.

Which employees would those happen to be?

Never seems to shake out that it's the ones at the top.

And this is the essence of the issue: complexity in one place often makes simplicity elsewhere.

Did it make sense for Microsoft Word back in the day to have a Fax option? Of course not. Unless you had a fax machine and needed to do a lot of faxing, then it was super convenient that your word processor knew exactly how to do that.

That seems like a feature, not complexity? It's not like it made deploying MS word any harder to add the fax button.

Features interact combinatorially, which introduces complexity.

Faxing isn't a great example, since from the perspective of most other features, it's probably just a special case of printing, but you can imagine it made it harder to build a web-based version of Word (what number are you faxing from? How does the computer in the MS data center contact or emulate it?)

Heh, there is some saying along the lines of "Any one customer only uses 10% of the features your software provides, the problem is each customer users a different 10%"

It's almost always a better bet to add more complexity to your product to capture more market than to make it as simple as possible.

The underlying OS could already do faxes (by treating them as a special case of printers and popping open an OS-controlled dialog to accept phone number &c). But Word bypassing all of that with its own fax drivers and protocols meant it could provide a full UX for the end-to-end of faxing (including, probably most importantly, scripting the fax send so you could merge from a phone number database)... At the added complexity of replicating an entire feature the OS already offered a slightly different way.

Exactly this!

My first principle in building software is:

Avoid Writing Code.

Code takes time to run. Code is habitat for bugs. Avoid it. Do everything possible before writing it to minimize it — think, plan, select better algorithms, data structures, process models, etc. Write and test toy versions to select the most streamlined. Of course some code must eventually be written, but doing the work to avoid it pays off.

Car analogy lesson; my coach in sportscar racing once asked me what things I do as a driver that slow me down on the track. I started to say something about "when I initiate the turn too harshly it generates more scrub and....". "No, No, I mean the big simple things...". "Well, that would be braking, turning, lifting off the throttle?". "Yes, so always avoid braking, turning, and lifting.". Obviously, doing all three becomes necessary at the end of the first straight going into Turn 1, but the point is that there hundreds of times where we'll do those things without thinking, and eliminating the unnecessary things that slow us down is one of the primary keys to fast lap times. The fastest drivers make FEWER moves and are much calmer in the cockpit. That simplicity takes a LOT of dedicated work.

Similarly, eliminating unnecessary code takes a lot of dedicated work, but it is critical to software that performs.

Spend the effort; it's worth it.

Avoid Writing (and including) Code.

TBH if we could boil software metrics down to a immediately gratifying metrics like lap time or race position, it would make things a lot easier to figure out what simple means.

First thought: 'Ya, that would be nice'.

Second thought: 'Wait, we have metrics on execution time, time-to-load/display, time to download, file size, etc, and can even count clock cycles required.'....

And, it's kind of like auto road racing, where the times only matter in comparison to other times of that particular car class, at that specific track, in the configuration for that race, on that day's weather conditions, etc. Software is similarly comparable only to software of the same type/class, and how well the earlier versions of that software performed.

It's almost like we can gather more performance data about software than we can about sportscars...?

Which is better, a car that completes a two lap race with laps of 1:00, 1:00 or with laps of 1:30, 0:15.

Which is better, software that used the twice has a time to first paint of 3 seconds, 3 seconds or 4.5 seconds, 1 second? The second obviously benefits from caching.

There, it's no longer obvious because there are competing goals.

Said like you are proud to have found some kind of "gotcha"; it's a cute example, but I don't see the relevance.

The goal the article, GP and I mentioned were simplicity and reducing amounts of code, and the comment was about how we have the ability to measure our code 's performance.

Yes, immediate fetch every time vs caching is a question of competing goals. The default approach would be to avoid adding the code and complexity of caching. BUT, and that is a big "BUT", if the context of the software's use requires it (e.g., cached uses are far more numerous than fresh and using cached values will not screw up the results), then add it, and be efficient about it.

What's the big deal, what am I missing?

Other than basic politeness (that's a rude and dismissive opening on your post) my point was it's easy to know what "optimal performance" means when racing, or generating a profit. Software requires optimizing some aspects at the cost of other aspects, which is a business decision.

Like the best race car races the race the fastest, the best company makes the most money over the time period you care about. The best software could be optimized to load for new users fastest to reduce new customer bounce rates or to work best for returning loyal users to reduce churn or several other metrics. It's a legitimate question of what you want to optimize for

Yes, it is clear that software can have different options or questions of what to optimize for.

That still seems orthogonal to, or at least a separate consideration from, the question of minimizing the code.

Of course what to optimize for should be as carefully considered as any other factor. It is kind of the core point of a design effort.

The developer or team should figure out what to optimize for, then figure out how to implement that with the least possible code. Of course, some optimizations will require more code than others, and that should be one consideration (e.g., "yes, feature XYZ is cool, but is it worth the amount of code — slowness & bug habitat — that it will require?") in deciding whether or not to implement it.

So, I'm still not seeing how your point is an argument for writing more code, or invalidating the principles in TFA or the above posts? It just seems an offtopic distraction?

> Avoid Writing (and including) Code.

What's your thoughts on no code platforms, such as:

-bubble.io

-airtable

-power apps

-nintex/appian/etc.

I find myself looking at these platforms because the client server model we all have been been doing, still has a lot of boilerplate that needs to be setup.

At least with these, the selling point is we can focus on the logic and look, which is all the paying clients really care about.

...In defense of boilerplate, think about what you're actually doing.

You're plumbing a pipe of tangible meaning through networks of functions as implemented in electronic signaling devices.

Creating and propagating that significance takes work. Embrace the boilerplate. Also acknowledge that every no-code tool has about a gazillion engineer hours lying in wait because what you want to do is hidden and sieved through somebody else's abstractions.

I haven't tried any of them, but they could be fantastic for prototyping, first throw-away versions, and projects that don't really matter.

For real r2.0+ production versions on projects/products that matter, I'd be suspicious that there are huge layers of libraries that get included, lots of code to run slow and provide bug habitat. But, it could also be that the developers have some optimization passes that strip out unnecessary code. It's something to check out carefully before committing. Of course, using one for a first throw-away version and examining it in detail can provide much info.

But no company would give you time to think that much. In opposite, we have to hurry to code and show something by the end of the day

It's not always like that.

Take for instance washing machines. They aren't conceptually complicated from user perspective. More or less, they have well-defined configuration parameters. You don't need a complex model of a washing machine in order to successfully operate it by any stretch of imagination.

That is, unless you buy a modern washing machine... where instead of having separate controls for water temperature and time you get a single knob. In most cases it doesn't even have a line on it to show which direction it points. It's just a round knob you can rotate endlessly. When you rotate it, in seemingly random order the lights near cryptic icons go on and off. Even if you can sort-of guess what a particular icon might mean, you will have very hard time finding a combination of the desired temperature and time.

And this is not unique to washing machines. Try toaster-oven, or water boiler, vacuum cleaner, air conditioner... modern day household electronics have the most idiotic design in their entire history. And they aren't conceptually hard to use. People who came up with the interface made it unnecessary complex and convoluted. And it's not a one-of event. This keeps happening all across the board, different brands, different kinds of equipment...

My explanation to this is not that it sells better: I'd absolutely buy a washing machine with text labels instead of icons. It's some kind of bizarre trend where manufacturers think it's more "stylish" this way.

Hell, take modern furniture or bathroom equipment for example. There's a bizarre trend to avoid showing the screw caps. It makes installing stuff much harder and the final installation more fragile and suspect to accidental damage... and yet it's nigh impossible to find simple(r) alternatives which would be durable and easy to assemble.

The icon thing is so they can sell the same appliance everywhere without localizing it. (Of course, they still have to localize the manual but their inventory management is simplified.) That doesn't help you though.

Precisely. If you want text labels and you're trying to sell the same washing machine in Japan and Germany, you've just given the user interface designer the challenge of writing labels where there's a 10x difference in the average length of the symbol.

Making up novel hieroglyphics and letting the user memorize them is just cheaper.

Can you match the icon to the icons in clothing labels?

>If you want text labels and you're trying to sell the same washing machine in Japan and Germany, you've just given the user interface designer the challenge of writing labels where there's a 10x difference in the average length of the symbol.

No one sells the same washing machines in Japan and Germany. In Japan, the washing machines are made only for the Japanese market, not for export (some are imported from China, but these too are specifically made for the Japanese market, and are very different from machines sold elsewhere).

The cheaper machines have all text labels, and a lot of buttons, all in Japanese. The fancy machines like mine have touchscreens, with an enormous number of different settings and functions, and again it's all in Japanese with no ability to change languages, there there are also some icons along with the text, but not enough to use the machine without reading Japanese.

You really think it would make it very difficult to localize "time" and "temperature"? -- because these the only two labels that are actually needed for a washing machine. I would even take icons for both. Something that looks like a clock face and something that looks like a thermometer would work just fine.

The problem is that it's not even close...

Also, I worked in printing, specifically flexo / silk / tampo, i.e. the stuff that gets printed on all sorts of curved surfaces, stickers, souvenirs, mugs etc. Yeah, it adds a bit of complexity... but compared to the price of equipment, at least the printing part is nothing. It might have to do with packaging and managing inventory for different languages... but then again they also need other localized stuff... so who knows.

> It might have to do with packaging and managing inventory for different languages

Yeah -- it's not a localization problem, it's a supply chain problem. By removing the need to localize, they can manufacture and deliver a single SKU to any location. It's the same reason manuals are printed in 12 languages.

> That is, unless you buy a modern washing machine... where instead of having separate controls for water temperature and time you get a single knob. [...] When you rotate it, in seemingly random order the lights near cryptic icons go on and off.

Maybe washing machines are different in your market to in mine? In my region washing machines [1] have a dial, labelled in english, listing programs like 'cotton' and clearly labelled push buttons for temperature and spin speed.

I could only see one that doesn't have such an interface [2] and it comes at a substantial premium.

The UI situation with washing machines is much better than for things like smart TVs.

[1] https://www.johnlewis.com/browse/electricals/washing-machine... [2] https://www.johnlewis.com/miele-wer865wps-freestanding-washi...

This is the one similar to the one I have: https://www.lg.com/us/washers-dryers/lg-wm6500hba-front-load... . I also had one before it from a different manufacturer, but cannot find it at the moment.

Also, I really don't want programs like "cotton" either. This just doesn't mean anything really. It's just noise. I want two dials, for time and temperature.

A modern washer will self-select time based on the amount of clothing. This often cuts down the time needed from what the user thought was needed.

I want two dials, for time and temperature.

For me a washing machine without a wool setting and where I cannot control the spin cycle is an instant no. On the other hand I have no use for time dial, as I would expect the washing machine to work that out for me. Which is the problem manufacturers have, your must have feature is useless to me and my must have feature is useless to you. So either they have to make two different models of washers or they have to try to combine all the features into one machine.

The weird thing is that what you are describing is a very American washing machine. What I'm used to from Europe looks more like [1].

You select the desired program with the knob based on what you loaded, then adjust temperature and spin speed with the touch inputs (some programs will block out some options, e.g. wool won't let you do more than 40°C or 800 rpm), you can add some options like more water, and based on that the machine does its thing, running a program specialized to achieve the desired outcome. It tells you how much time it needs, but it's not something you have manual control over.

And of course everything is labeled ... printing different text on a $200-$2000 machine doesn't break the bank for non-american manufacturers.

1: https://media.miele.com/images/2000018/200001856/20000185612...

>The weird thing is that what you are describing is a very American washing machine. What I'm used to from Europe looks more like...

Absolutely true. Machines in Japan don't resemble his description at all. My machine has a touchscreen with a ridiculous number of options and settings, all printed in Japanese, along with 4 physical buttons (on, off, start/pause, and back). The cheaper machines don't have a touchscreen, but instead a bunch of buttons that basically do what yours does. Knobs don't seem to be a thing here (on washing machines; they are on the fancier microwave ovens though, strangely).

Refrigerators are another one. A top freezer is simple because on the coolant loop that’s the coldest area, keep it cold until it produces refrigeration level temp and then as it warms return it to the compressor at the bottom using gravity. But everyone wants freezers at the bottom, or french doors so complexity is added to fight physics.

Last air conditioner I bought (and returned) had Alexa built in but not the ability to keep the fan running all night.

There is a difference is a freezer on the bottom or French door isn't just aesthetic. It changes how people use the fridge. Bottom freezer drawers are easier to random access, for instance, and don't lose as much of the cold when open, and thus are a good solution for people who freeze a lot of stuff.

That it, it makes the physics harder but produces a payoff.

It’s probably true of most complexity, it’s added for a functional purpose and payoff, but takes away from the simplicity.

People choose the complexity of a bottom freezer, but in this case the complexity of the choice isn’t even apparent to them. It’s unlikely to keep running as long as a top freezer fridge from the 80s or 90s, but they don’t know that when buying.

That old school simpler design you refer to has its own problems, relying on a fixed ratio of cooling where you often get either a warm freezer or cold fridge. See https://www.youtube.com/watch?v=8PTjPzw9VhY

Modern fridge/freezer combos want to control the ratio of cooling. This is often done as simply as controlling a fan that moves cold air between the compartments.

These designs are usually added to show the executives of the company that a branch of the org chart and its Important People can "add value".

Conversely, the fastest way to turn around a failing company is to search through company e-mail archives, find everyone who has ever used the phrase "add value", and purge them from the company.

> the fastest way to turn around a failing company is to search through company e-mail archives, find everyone who has ever used the phrase "add value", and purge them from the company

but you'd purge the entire c-suite if you did that!

I fail to see the problem with that

Thanks for finding the perfect quote for what my thoughts were as well.

I'll also add that simplicity also comes from a lot of experience, since the most dangerous developers now seem to be the ones with minimal skill, that don't have the track record to understand that they can't predict what the future will hold, and should better just solve what's required while keeping their options open.

Your comment is also a quote by itself

But all too often people fail to appreciate a tasks’ inherent, essential complexity that draws a simplicity line.

Sure, in the general case people are way above that line, but we also see the reverse (e.g. claiming that systemd is “bloated”, when much of that complexity is required for that problem space).

Too true. I think the quote hits on this part where Edsgar is saying that it takes education to appreciate simplicity. Some problems have an inherent complexity to them and to appreciate an elegant solution that is sufficient to the task requires some training and understanding of the problem. It's a bit subtle perhaps but I think it's important to understand!

It's also a fantastic recipe for getting out of touch unjustifiably with the rest of the world, and shooting down completely valid input.

"You just aren't intelligent/smart enough yo understand/appreciate the elegance of my design" is the cope of many a fragile engineer in the face of a real world bashing their head against something rendered unnecesarily complicated for reasons completely tangential/unrelated to intended use.

The proof of the pudding is in the tasting in such cases. If you can't explain it to someone else then you definitely don't understand it. Ask a few questions and fragile egos tend to reveal themselves.

Oh, it can be the case you absolutely do understand it, you can explain it, you can point out line by line, and class by class what you wrote, and why it makes the people whom you wrote it for's life easier. You can also document it, and provide references to external docs you relating to frameworks you depend on.

That still will not convince some that cannot be bothered to track where their bits are.

I bring up the point because I've whipped up a system specifically intended for shipping a declaratively defined DB state, to a particular user specifiable environment, whilst limiting thr actual implementation of said data as close as humanly possible to forms that were already being written.

There are just some times when the needed solution will not be accepted until people have rammed up against the problem they don't even know they have. Thus is the curse of the implementer that prevents rather than remedies.

Make a problem impossible to occur and people think you over engineered it. Sit on the answer til everything is on fire, and the migration cost is maximized, and you're looked on as a visitation from on High.

It...really...sucks.

Oh I get that.

Sometimes people mix up simple with familiar, easy, or shallow. They expect that they won’t have to learn anything or that understanding should come without effort. Unfortunately this is not the case.

I often use the word sufficient in place of simple when trying to convert this to an audience that isn’t familiar with the subject matter. It’s as simple as one can make it without waving our hands about the essential complexity of the problem itself.

The proof of Cantor’s theorem is conceptually simple but there are plenty of people who cannot appreciate it because they understand little enough maths. And yet the theorem serves as a basis for more interesting theorems and practical applications.

I also try to avoid the use of the term, over-engineering. I find it is often thrown around too easily and used derogatorily.

Reply on news.ycombinator.com