Hacker News Reader

Comment by aemreunal | Hacker News Reader

> 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.

View on HN

"Any idiot can build a bridge that stands, but it takes an engineer to build a bridge that barely stands."

- Someone

Brilliant!

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").

And who came up with that framework?

With different constraints...

"The perfect race car crosses the finish line first and then completely disintegrates"

- Ferdinand Porsche

(I took some liberty with the translation - the idea is that everything breaks at the same time.)

"The perfect racing car crosses the finish line first and subsequently falls into its component parts." ?

* https://quotefancy.com/quote/1791488/Ferdinand-Porsche-The-p...

"An engineer can do for a dime, what any idiot can do for a dollar" - Someone else

[edit] Achshually "An engineer can do for a dollar what any fool can do for two" - Arthur C. Wellington

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?

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.

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.

> 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.

If we designed aircraft the way we design consumer software nowadays, every plane would have sixteen rocket engines and two seats.

Except that we'd want to fly that.

Well, nine of the engines are pointed forwards.

And one of the seats doesn't recline.

Not in the free version, anyway.

We see the same in other areas.

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.

> the average web browser and connection is fast enough to serve Wordpress content in an acceptable time for the user

...That's because (unless something has changed in Wordpress relatively recently) what the browser receives is, in fact, "flat HTML".

Wordpress is written in PHP, and all the processing happens server-side.

All true. But I was referring to the server side.

If HN had an equivalent of Reddit Gold, this comment would deserve a couple of them.

Engineering without constraints is easy, but it's not engineering.

Engineering without constraints is theory.

Or Product Management?

*Marketing.

Imagine a world where our currency is decentralized and the user owns their own data!

kek.

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.

Programming in Haskell.

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".

> Ok. What is the art of building things that are good, but violate some constraints of the real world?

Science fiction.

Somebody designs user interfaces for use in Hollywood movies. They don't have to be practical or even feasible, they just have to look cool.

> What is the art of building things that are good, but violate some constraints of the real world?

Magic.

> 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.

Reply on news.ycombinator.com