I think that's what's offensive to the purist engineer mind. These aren't engineering decisions, they're business decisions (or maybe the closest thing you could call them would be "financial engineering" decisions). The best thing, by pure engineering criteria, is not what gets built. The best thing for the business is what gets built. In that context it's a complaint as old as the hills.
...and not specific to computers either, or even the private sector. In a past career I was a civil engineer, and I learned about how traffic light green times (how many seconds a signal stays green for one direction vs. the cross street) usually have a "right answer" from an engineering standpoint, which as you can imagine, has to do with maximizing traffic throughput and/or minimizing delays to each individual vehicle. And then the mayor of the town shows up out of the blue and says no, this direction is going to have a longer wait, I'm going to delay people intentionally, so that when they're stuck in traffic, sitting there, they'll have more of a chance to see signs/placards of, and contemplate patronizing, nearby businesses, whose owners are my political backers. That made a big impression on me... must have, because I feel like I've told that story in an HN comment before... but anyway... yep.
> These aren't engineering decisions, they're business decisions
All engineering (including "real" ones like civil or mechanical) is about fitting your requirements within budgets. When one's building a skyscraper, you try to build it in a way that minimizes the cost while satisfying all requirements (it shouldn't fall down given such and such conditions, etc.)
Engineering is largely the art of solving problems that fit in real-world constraints and one such [major] constraint it cost. When you build software, you're not given 10 years, a research team and infinite money. You're given just enough resources to build something that satisfies requirements and is the lowest cost (financially and temporally). There's always a way to build things "better" but that's not the point.
Your quote is better, but for people that have a hard time with that analogy, I like using the example of building a 4-story concrete/brick building - anyone can make a building stand strong by filling it with concrete / bricks. It takes precise engineering to know how thin you can make the walls/supports to make that building worth building.
If you just mindlessly fill everything with bricks and concrete, you likely need to make the lower walls thicker than the upper ones to support the weight...
The whole engineering process can be done without ever looking at the budget as long as the framework is given ("use these materials", "you have this much space").
Feels like everyone is very disinterested in the cost to the user with most "modern ways" of doing things. Many webpages use far too much resource to just communicate text. Web adverts are especially awful for this. I could browse the web with dialup and a machine a thousandth as powerful as my phone. So as a consumer why do I need to "upgrade" what was the added value above Google scale is delivering computationally intense adverts I then waste cycles blocking?
Of course they are, because the user does not reward them for being sparing of resources that are, frankly, insignificant on modern devices. Might be different in you were operating in a market where people were largely relying on very low-powered devices, though.
That's a circular argument, because "on modern devices" moves the goalposts every year. I still have a Galaxy Note II, which I would definitively classify as a modern device. But some webpages have terrible performance on it, because anything older than 3 years is not worth optimizing for.
Same thing with old iPhones: the only reason they don't work reliably today is because each piece of "modern software" is less efficient than yesteryear's equivalent, and the constant redefining of what constitutes a "modern device" is what perpetuates the problem.
This isn't an engineering problem, it's a consumerist dystopia. The computing market is encouraging wastefulness in all dimensions: useful device lifetime, computing costs (bitcoin farming anyone?), software efficiency, framework longevity (jquery, angular, meteor, react), dependency management (NodeJS). None of those problems are new, but every new entrant seems hell-bent on outdoing the wastefulness of its previous incarnation.
Perhaps a circular process. Not a circular argument. It's just reality that users reward optimization they can't really notice less than features. In places where it does matter to the bottom line, like how fast a shopping page loads, the optimization is prioritized.
But the cost to the user is not considered, even in the real world. For example, transportation decisions are made in the airline industry, and they rarely consider how much this will financially impact the lives of passengers. The same pattern is replicated everywhere: companies work to maximize their profits, while their clients have to deal with possible financial losses.
Desktop OS's are not appreciably faster now than they were 30 years ago, despite exponential rises in memory, storage and processor capacity. Better looking, yes, but not faster.
Games have maintained roughly the same performance for 20 years. However, the number of polygons has risen exponentially.
There's a minimum acceptable performance for most systems. If you exceed that, no-one cares (the extra performance is wasted). So every system hits that minimum performance level and spends the rest of the budget on appearance (or configurability, or ease of editing, or whatever).
Wordpress is slower than flat HTML. But the average web browser and connection is fast enough to serve Wordpress content in an acceptable time for the user. The "extra" budget was spent on making it easier to create the content.
> Feels like everyone is very disinterested in the cost to the user with most "modern ways" of doing things.
The only time a decision maker actually cares about the cost to the user is when they are trying to calculate how much money (or savings) they could capture from the user.
Proper engineering also takes into account the end users, even the ones that aren't paying for it. If other engineering disciplines were as hell-bent on cutting corners as SWE, these situations would be common-place:
- "cars older than 5 years are not supported on this bridge"
- "Sure, we can perform maintenance on this bridge, but with every round of maintenance work, the maximum speed across the bridge will be lowered by 5mph"
- "No, I'm sorry, you can't call our office from a landline. We only accept support calls from a Sprint mobile device, and the contract must be less than a year old"
- "What do you mean, you need to replace a fuse? You can't do that, they're built-in. Please contact our office to buy a new house".
- "Sure, our new Model T does 5 gallons to the mile, but look at its color! It's not just black, it's Vanta Black (tm)! And look at these rounded bumpers, aren't they a marvel of engineering?"
I wouldn’t be surprised if solving the problem with the Mayors constraints increased costs though.
I have a few stories where senior management, or a preferred developer had some pet project. Or crazy ideology. So we adopted that dispute protests. If we picked a standard way we would have been done faster, cheaper and with fewer bugs.
But you can do this satisfying requirements with different interpretations: here in HN we cry and whine when database queries are not efficient, when code is suboptimal, when sites are hacked and leak info and many more things. These things were all probably fine within the requirements. Just like this crap experience for the user with Electron. So where do I draw the line? And why?
Ok. What is the art of building things that are good, but violate some constraints of the real world? I’d like to use the products from that discipline.
Jokes aside, do you really not understand what GP means? "Real-world constraints" are the things like having to make money or having to do something with only 2 other programmers to help you. Nobody's claiming that, for example, academics (who don't need to have products that money) don't have other problems (like grant writing or juggling academic responsibilities), but that isn't what people mean by "real-world constraints".
> What is the art of building things that are good, but violate some constraints of the real world?
“The romans were so much better at building stuff”.
You could make buildings matching those, they’d be massively over-engineered and overpriced compared to the modern equivalent, and significantly more limited in suitable locations.
also within time constraints, building an electron app in the scenario outlined is probably a lot quicker. Normally building something quicker implies that later maintainability is adversely affected, but in this case the tradeoff is not time vs. maintainability, but time vs. performance.
Performance has generally been getting the short end of the stick since early Windows days anyway when Gates had people build not for what a computer could handle when the application was built, but rather what it could handle a year down the road.
>When you build software, you're not given 10 years, a research team and infinite money.
So actually you don't need all that to identify when there is a bird in the picture anymore, what's the new bird in a picture requirement? https://xkcd.com/1425/
> also within time constraints, building an electron app in the scenario outlined is probably a lot quicker.
But building it in Free Pascal/ Lazarus is (almost?) as portable across systems, probably at least as quick, and comes without all the horrendous overhead bloat.
Its best to understand early that an Engineer deals in two commodities: money and time. Their job is not to create ivory-tower ideal solutions. The whole problem, the reason Engineers exists, is to manage technology such that the constraints of money and time can be met.
You know, I hear this argument a lot for e.g. why Slack is a dog slow electron beast.
The thing is, slack has not been short of time OR money for at least the last 5 years. They could have easily built leaner, faster native apps and customers would have appreciated it.
This "ivory tower" stuff smacks of just world/just market fallacy.
I suspect there are deeper issues here. For example, vendor lock-in inhibiting competition paired with the "electron app team" being a powerful fiefdom within the company.
IME the concealed undercurrent of politics tends to provide a better explanation for many hard to understand decisions at large companies than unexpected technical prudence. Why does Uber's app require 150 developers? Why is Facebook's app such a beast? Why did they create a whole new "lite" app rather than slimming it? Why does Google have 13 messengers?
Reaching for a calm, rational engineering decision to explain each case is tempting, but wrong.
So once you have an app up and running, with millions of satisfied users you would hire another team of more expensive developers to build a native app.. for each platform? so make that 2 more teams or rather 4 more teams? (iOS, Mac, Android, Windows)
Telegram already does this with a rather small team. Hell, there are even third-party Telegram clients that, while a bit behind the features, eventually catch up with every single one.
You don't get to be a billion dollar company by spending money unnecessarily. The question is never the total size of the company the cost relative to other options.
See, this is interesting to me, because I come from a different engineering background and was taught that the constraints were safety first, then cost. Time to build was a part but not as important as those other two.
Obviously safety is a bit less important in the software world, but hearing time be a key part of an engineer’s focus makes me uneasy for some reason, even though it makes a lot of sense from a business perspective.
The saying about optimization goes, "Time, Cost, Quality: Choose two." You've chosen the two that most profit-minded entities choose, but they are not the only choices.
Optimizing for quality and time can be a winning solution, particularly if you can achieve novelty as well. Countless corporations and founders have had success with the strategy (Apple under Jobs comes to mind.) Optimizing for quality and cost is also viable: Deming preached it, and e.g., Japanese car manufacturers have showed it to be a highly successful strategy.
yeah but the problem is: which budget are you optimizing? That of the company of course. You offload a lot of bullcrap onto the end user. Like the author said, wasting electricity and battery life and thousands of devices just because you cant be bothered to generate html on the server to serve simple text is a common thing for news sites.
This is wasting the time as well of the end user, because its slower to load, and lower performant on the device itself
> yeah but the problem is: which budget are you optimizing? That of the company of course.
The budget of the company is predicated upon what the user will be willing to pay for the service.
You’re wasting electricity and battery life of thousands of devices of users who don’t care or want to “vote with their feet”.
Now obviously users are also constrained by what is made available to them, but time and again the shiny and early to market wins out even if it’s a literal trash fire…
Let's not pretend that such business decisions are following rules written down on stone tablets passed from above. They're nothing more than going with the flow and following the path of least resistance in a market that painted itself into a corner of inefficiency and technical inferiority. Chiefly because of Google's empire building, VC money and the quest for millions of users.
Those two facets of quality, or the lack thereof in the applications which are being discussed are undeniable and the offence will continue to be perceived until the underlying problems are resolved.
Watching the rhetoric of the web dev community over the years, I have the impression that previously they thought that the one big technical improvement will come and that will allow them to compete on equal footing with native applications. Now they've given up and just mumble something about Electron being cheaper - an improvement, even if far from the ideal :-)
> And then the mayor of the town shows up out of the blue and says no, this direction is going to have a longer wait, I'm going to delay people intentionally, so that when they're stuck in traffic, sitting there, they'll have more of a chance to see signs/placards of, and contemplate patronizing, nearby businesses, whose owners are my political backers.
You gotta be kidding me! Not only are we subjected to this constant visual pollution in the form of advertising but these politicians deliberately make traffic less efficient in order to force us to "contemplate" this garbage?
That's extremely offensive and not just in the purist engineer sense. The audacity of these people to think they can literally hold you down and force their little commercial interests into you.
> the mayor of the town shows up out of the blue and says no, this direction is going to have a longer wait, I'm going to delay people intentionally, so that when they're stuck in traffic, sitting there, they'll have more of a chance to see signs/placards of, and contemplate patronizing, nearby businesses,
> [...] usually have a "right answer" from an engineering standpoint, which as you can imagine, has to do with maximizing traffic throughput and/or minimizing delays to each individual vehicle [...]
Another common problem is when an Engineer is told to maximise a specific variable, rather than apply their wisdom to determine _which_ variable to optimise.
Optimising for more cars usually means that public transport can't improve, and moving around gets worse for pedestrian/bikes. Ultimately, mobility does not improve, and you just need more cars and more car lanes. Car flow improves, but nobody stops to think if that's really the most important thing to improve.
> "The best thing, by pure engineering criteria, is not what gets built."
How do you define the "best thing, by pure engineering criteria"?
The least memory/CPU? Or the smallest download size?
These are somewhat irrelevant vanity metrics in most cases... they're especially vain, if optimising them loses you potential clients and makes the project a failure...
Well it's a net negative for the end user, which should have been the priority for everyone involved, and what you're describing sounds like a corruption of this system. So I wouldn't call it an engineering thing, it seems far more general than that.
>> Well it's a net negative for the end user, which should have been the priority for everyone involved
I feel like you're missing the point. Let's say you are a product manager. Here are your options;
A) increase the product price so the budget can be bigger. Understand that increasing the price will lower customer numbers, but net inflows may be larger. (does this option prioritise the end user?)
B) spend all your budget on platforms with the most usage. Ignore less-used platforms completely, but deliver the best possible for your selected platforms. So 100% spend on the Windows client - - and of course ignore Apple and Linux desktop. (does this prioritise the end user?)
C) build a cross-platform solution that is sub-optimal on all platforms, but targets multiple platforms on a limited budget. This reaches the most people, but the experience from an engineering point of view is less than ideal for all of them. (does this prioritise the end user?)
How you answer depends on who you consider the end user to be.
If you see them as "people who have bought our system on our preferred platform" then option B makes the most sense.
If you see them as "people who could use our system to improve their lives" then option C makes the most senses.
If you see them as people who can afford fine engineering then go with option A.
On the up side, no matter which one you choose you are prioritising the end user, so it fulfills your premise.
I don't consider it a "net negative" that I can use a bunch of stuff on every device I own rather than just one or two. And frankly, if you happened to be involved in the sysadmin world during the long, slow death of Windows XP, you might even appreciate the benefits of Web apps even from the technical standpoint.
I'm sure COBOL programmers thought the same. Some day all the existing QT programs will need people to convert them to something else. Keep those skills sharp.
Indeed it is, however the end user is probably not the customer of the business. The business is serving its customers. Sometimes end user = customer. But often they are different sets of stakeholders with their own priorities. I'm not saying businesses go out of their way to piss off end users, but customer needs trump end user needs.
...and not specific to computers either, or even the private sector. In a past career I was a civil engineer, and I learned about how traffic light green times (how many seconds a signal stays green for one direction vs. the cross street) usually have a "right answer" from an engineering standpoint, which as you can imagine, has to do with maximizing traffic throughput and/or minimizing delays to each individual vehicle. And then the mayor of the town shows up out of the blue and says no, this direction is going to have a longer wait, I'm going to delay people intentionally, so that when they're stuck in traffic, sitting there, they'll have more of a chance to see signs/placards of, and contemplate patronizing, nearby businesses, whose owners are my political backers. That made a big impression on me... must have, because I feel like I've told that story in an HN comment before... but anyway... yep.