Live data from Hacker News

Imaginary problems are the root of bad software

cerebralab.com

501–510 of 511 posts

Re: Imaginary problems are the root of bad software

#501

I gave up on this article when I found out that the first hypothetical scenario has no relation to reality. Implementing something else “because if they implemented the real spec they would get bored” is too much psychology.

The author seem to infer whatever he needs to affirm his opinions, examples are poor and the whole thing is just a rant disguised as reasoning.

Re: Imaginary problems are the root of bad software

#502
post #311

Earlier quoted context omitted.

There's a reason in-house corporate software started becoming web based 15-or-so years ago: web is cheaper, easier to hire for, faster to develop and deploy, doesn't require installation or updates, easier to troubleshoot, doesn't need special pipes for communicating with the server (yeah I remember the days of DCOM, CORBA, WCF and other weird protocols instead of HTTP). It is things like Qt that only HN and online n…

No, long term, web apps are more expensive because the front end needs to be completely re-written ever few years. A desktop app written in Qt can be kept running for a decade with very little work. (This assumes no Qt library upgrades, which for in-house apps, are most unnecessary.) The primary advantage of web apps is "zero install", which is a major point of friction at large corps.

“because the front end needs to be completely re-written ever few years”

Citation needed. I’m currently working in a jQuery+Coffeescript app that still works like a charm.

Like the sibling post says, Qt itself had breaking changes that HTML/JS/CSS didn’t.

Re: Imaginary problems are the root of bad software

#503
post #311

Earlier quoted context omitted.

There's a reason in-house corporate software started becoming web based 15-or-so years ago: web is cheaper, easier to hire for, faster to develop and deploy, doesn't require installation or updates, easier to troubleshoot, doesn't need special pipes for communicating with the server (yeah I remember the days of DCOM, CORBA, WCF and other weird protocols instead of HTTP). It is things like Qt that only HN and online n…

No, long term, web apps are more expensive because the front end needs to be completely re-written ever few years. A desktop app written in Qt can be kept running for a decade with very little work. (This assumes no Qt library upgrades, which for in-house apps, are most unnecessary.) The primary advantage of web apps is "zero install", which is a major point of friction at large corps.

> ...needs to be completely re-written ever few years.

No it doesn't, the HTML spec hasn't changed, whereas QT has. The issue is how the webapps were built in the first place. You don't need Nextjs and all it's friends to post a form to a backend once an hour but somehow that is becoming the standard approach...

Re: Imaginary problems are the root of bad software

#505

If anything it's the incentive system in software industry, which is at fault. 1. No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives. 2. No engineer is paid extra for keeping the codebase without growing too much. It's re-writes and the effort he puts in to churn out more solutions (than there are problems) that offer…

Not universally true. Just find a manager who values successful delivery of project goals and is fine with "boring" i.e. tried-and-tested technology.

I blame Career-Driven Development for a lot of "shiny toy" (i.e. failed and complicated) projects.

Whether that's wrong is a deeper question - if it leads to better salary through job-hopping and promotions, despite a catalog of failures, is it actually the wrong approach from an individual engineer perspective?

I still say yes, FWIW; I enjoy seeing my projects succeed and thrive. But I know others may disagree.

Re: Imaginary problems are the root of bad software

#506
post #6

Premature optimization is the root of all evil. Simple > Complex. It's amazing how many otherwise brilliant people dive headlong into project without considering these basic principals or even intentionally brush them aside.

And now we will have AAA games with poor performance and DLSS slapped on. Maybe optimal performance is a feature? Feature worth working on from start?

yes we have experience very poor performance games i hope they working on it

Re: Imaginary problems are the root of bad software

#507

> secure online banking is actually quite an easy problem to solve . . . The storage and transfer of numbers is not a particularly hard problem. I don't know anything about banking software, but I have a hunch the author underestimates the complexity (as is typical for HN). The Efficient Markets Hypothesis would suggest that if it were so simple to make banking software, then someone would do it.

The shareprice of META fell by 75% from August 2021 to August 2022, wiping about three quarters of a trillion dollars off its market cap. From October 2022 to now the shareprice tripled, adding half a trillion dollars to its market cap. Explain that in terms of the Efficent Markets Hypothesis? "share prices reflect all information" - what half trillion worth of information change came out in 2022? and what in 2023? W…

1. Apple made iPhones more private so Meta can't target ads as efficiently

2. Interest rates affected the entire market

Re: Imaginary problems are the root of bad software

#508
post #224
post #145

Earlier quoted context omitted.

They succeeded because of php. It was easy to use for them. So it enabled them to materialize their ideas. It was the right tool for them. Anything else would have been fine either way, if it was the language they were the most comfortable with. In their case, it happened to be php.

That just sounds like "they succeeded because they knew a programming language", not that it was right one compared to competition

No, they totally succeeded because the used php. I think zuckerberg said it himself that php allowed them to add new features easily. I think he mentioned that it was easy for new people to pick it up. I’m pretty sure Facebook wouldn’t exist today if it had been written in the more corporate/esoteric languages available at the time.

Its ease of use allowed him to launch the site from his dorm room. Iirc, YouTube was also written in php (it had .php urls), before google bought it and rewrote it using python, so you could probably thank php for that site too.

Re: Imaginary problems are the root of bad software

#509
post #508
post #224

Earlier quoted context omitted.

That just sounds like "they succeeded because they knew a programming language", not that it was right one compared to competition

No, they totally succeeded because the used php. I think zuckerberg said it himself that php allowed them to add new features easily. I think he mentioned that it was easy for new people to pick it up. I’m pretty sure Facebook wouldn’t exist today if it had been written in the more corporate/esoteric languages available at the time. Its ease of use allowed him to launch the site from his dorm room. Iirc, YouTube was…

Just checked. It appears it was indeed first written in php then changed to python then to java.

Re: Imaginary problems are the root of bad software

#510

If anything it's the incentive system in software industry, which is at fault. 1. No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives. 2. No engineer is paid extra for keeping the codebase without growing too much. It's re-writes and the effort he puts in to churn out more solutions (than there are problems) that offer…

> No engineer is paid extra for keeping the codebase without growing too much. I am. I'm paid more than most developers to run a team doing just this. We make minimal change, have an absolutely non-negotiable focus on stability and minimalism and reject any change that isn't absolutely driven by validated majority user need. Even then, the bar is high. I'm not saying this is a common situation, but it certainly isn't…

I’m also I’m a similar situation, but I get the call when the thing has been on fire for a while so it’s a lot easier.

I can’t imagine a software engineer developing an interest defensive software engineering will be very visible until after there has already been a crisis to screw people’s heads on straight.

A lot of people seem to see “Do things that don’t scale” and think that’s a phrase meant for engineering.

Post reply on HN