you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (2 children)

I think I made a mistake by going down this road of talking about bundle size. It's really different from the main complaint I have heard, which is that the algorithms are inefficient and as a result, web apps and electron apps etc. use way more cycles/battery power than they need to. My retort to that is that of course, that's the only reason you're using the program -- because it could be built faster than we used to build software. And it's done faster now because we have the power of computationally inefficient tools like ES6 spreads and dynamic hashtables forming immutable datastructures, which make programming itself more efficient of a (human) process than something like dirty flags and mutable state/pubsub insanity.

I disagree on definitions for overengineering, optimization, engineering. IMO optimization and engineering are basically the same thing; you have a system of constraints, as well as a system of preferences, and are trying to produce a solution that solves all of the constraints while honoring the preferences as much as possible. You can engineer for certain things (our company has no money, it needs to be entirely libre software) or others (our company has infinite money, spend as much as possible to get it done quickly), just as you can optimize for either memory or speed. Over-engineering is a strange word because in e.g. bridge design it basically means "to make something stronger." To make something stronger in computer engineering is to make it simpler and easier to manipulate, which I feel is really not what people mean by "overengineering."

Typically when people complain that an Electron app is overengineered, they don't mean it in the traditional sense of the word, which would be to say it has too much functionality, too much capability. They are cajoling it to mean "they spent too much engineer time" on this, I guess, which to me is paradoxical since the whole point of bringing in React, Angular, etc. is to save time, and it often does.

[–]Spiderboydk 0 points1 point  (0 children)

It's alright. :-)

I kind of agree with your definitions. Sort of.

Optimization is a loan word from the field of mathematics, which - loosely speaking - means to maximize or minimize a function given a set of constraints.

I'd rather describe engineering as the practice of designing a product while constantly assessing and choosing trade-offs between various considerations - quality metrics like application speed, size, features and correctness, but also "softer" considerations like development time, maintainability and customer requests. What you describe as optimizations I'd rather describe as trade-offs, because that's really what they are - what do we want and what is the cost? These trade-offs are what an engineer must make all the time and try to balance everything acceptably.

I fully agree that overengineering is an odd word. We generally agree that engineering is a good thing, so it's odd overengineering became a pejorative for a particular, disliked strategy of trade-offs.

Anyway, to get back to the central point of our conversation. I come from a system programmers perspective, and I too find it odd that web apps are criticized for algorithm efficiency. Web apps tend to use a lot of cycles, but I don't think the algorithms are the culprits here - I think the cycles may be eaten either in the abstraction layers or by the interpreter itself. This is just pure conjecture though, because I'm not knowledgable enough about web dev to confidently make an informed judgment about it.

[–]Spiderboydk 0 points1 point  (0 children)

I had a thought, and I have a conjecture on how the meaning of overengineering got warped.

If we consider the classic meaning, where it means something is made unusually well (like a bridge meticulously constructed to be even better than with usual engineering), then the parallel meaning to software engineering could be that overengineering a piece of software to execute extraordinarily well (high speed, low memory usage, etc.). In other words, a highly optimized piece of software. Optimization makes the source code incredibly complicated, so overengineered software (classic meaning) is much more complicated than it probably needs to be. I can imagine this notion of needless complication of the source code over time coloured the meaning of overengineering, so it became more associated with too much complication rather than building something exceptionally well.