Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Imaginary problems are the root of bad software

cerebralab.com

Post reply on HN
Print view View original

271–280 of 511 posts

Re: Imaginary problems are the root of bad software

#271

Post by selcuka »

jakubmazanec wrote: post #207
pavlov wrote: post #90

Earlier quoted context omitted.

> “No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives.” This is a massive change from my first software industry job in 1997. I was essentially a “design intern who knows HTML” on a team that built a shrinkwrap Windows application for enterprises. The core of the design team was a graphic designer, a cognitive scienti…

I have another theory: it's all about the screen size. When you had only 320x240—1014x768, you simply MUST have thought about UX (in the sense of "How can I fit all this info in this little space?" Now you don't have to. So no one does.

This is true in a sense, but we now have a different restriction, called a mobile view.

Re: Imaginary problems are the root of bad software

#272

Post by eternityforest »

vinyl7 wrote: post #205
eternityforest wrote: post #203

The main imaginary problems I commonly see are wheel reinventions. For the most part, the software I see works well for what it does, and either has far too few features, or else all the extra stuff they added is stuff that people actually use. On social media things are different, that's been bad and unsalvageable from the moment endless scrolling made it into something people spend significant time on.

I'd prefer see wheel reinvention because it leads to better software. 1) it's debuggable 2) it's fixable 3) it does exactly what you need to do how you want to do it without any extra cruft and nonsense. Libraries or game engines are too generic to be fast and easy to use because they need to solve for every possible use case. And even then, there are still edge cases where what you want to do cannot be done because…

Games already cost an insane amount to develop. I would imagine that they would either have to have less content or less realism or cost more.

Plus, there's a limited pool of devs who can do 3D game engines(I sure can't!), the more wheel reinvention, the less available resources to do new things.

And then wheel reinvention also leads to incompatibility. For some reason it's fashionable for formats and protocols to include optional features instead of making everything mandatory. The big ones support all common ones, the DIY ones usually just support the options they need, and exporting from one and importing to another might do something weird, it takes a lot of work to support the de facto undocumented standard that emerges from sets of optional features with a few popular implementations.

Large libraries are debuggable too, because the reuse lets devs throw insane amounts of resources at debugging them even if it's really hard. And for the same reason, they can often be pretty well optimized. Modern software seems to be pretty fast now that Moore's law slowed a bit..

In theory, it's really cool that smaller solutions are fixable, but I'm just not sure we could actually have all this software everywhere running the whole world with small and simple in house code.... I mean, that's kind of what we had in the early 2000s, and while most things in general seemed better and people were happier.... everything that ran on a PC from the Win95 to the Win11 era seemed pretty insecure and unreliable.

Re: Imaginary problems are the root of bad software

#274

Post by gtirloni »

nine_zeros wrote: post #223
voz_ wrote: post #97

Earlier quoted context omitted.

Uber was a massive example of this. The best engineers kept their head down and just tried to keep things afloat, fixing bugs, etc. However, a large and insidious cadre of B tier engineers was constantly writing docs proposing meaningless arbitrary system changes and new designs for the sake the changes themselves. These new projects were the only way to get promoted. The entire e4->5->6->7 track was written in such…

The career ladder is among the biggest fuck ups of the tech industry. They incentivize bullshittery more than actual innovation. There are more rewards for BS RFCs than in keeping the ship running.

I had a completely different view of RFCs before coming into contact with some peers that followed this approach to the letter. RFCs for such small issues would take 10 pages and barely mean anything. Of course they would be praised by upper management (it didn't matter the RFCs would be ignored most of the time).

Re: Imaginary problems are the root of bad software

#276

Post by lazyasciiart »

wruza wrote: post #263
sirsinsalot wrote: post #239

Earlier quoted context omitted.

Am GP, it is finance based, but not commercial finance. Most of the systems handle complex calculations. The system is a monolith that has been around for 15 years or so. It isn't cool. It isn't pretty. Lots of it would be better for a refactor, but absolute stability is the goal. Refactoring things may result in long-term cost savings, but with risk. The business has no risk appetite, so it doesn't make sense. If it…

Interesting, I believe there is something to finance that allows or forces things this way. There’s much less fidget spinning and much more business in it for some reason.

Regulations, I’m guessing.

Re: Imaginary problems are the root of bad software

#277

Post by TehShrike »

muskmusk wrote: post #82
dtagames wrote: post #3

The author hits the nail on the head with his claim that imaginary problems are more fun than real ones. As developers and smart folks in general, we like complicated problems that are big and far away. How many times have I heard in a meeting, "Yeah, but when we have 1M users..." It's great fun to think your product will get to 1M users. It's also very unlikely. It's not nearly as fun to finish and ship and market a…

> The author hits the nail on the head with his claim that imaginary problems are more fun than real ones. Not necessarily. It's just that most developers have never worked in a setting where they got to work on problems properly. Solving real problems for real people is very addictive. There is a reason some people like working for startups. It's because you live very close to your users and when you make them happy…

Second this.

The endorphins from making someone's job less sucky are a way better high than solving some code puzzle.

Re: Imaginary problems are the root of bad software

#278

Post by lll-o-lll »

catmanjan wrote: post #265
mildavw wrote: post #94

Earlier quoted context omitted.

Yes. While it’s less common, I’ve seen orgs struggle because they didn’t have enough imagination. Every feature is done quick’n’dirty and eventually you have people whose full time job is to respond to customer complaints and fix data straight in the production database.

Bad engineering but potentially good business if it’s all billed to the customer…

No, it’s bad business because it doesn’t scale. Software is lucrative because you make it once and sell it to thousands of customers. If you’re making every customer their own bespoke thing, you’ll spend all your time for little return.

Re: Imaginary problems are the root of bad software

#279

Post by chii »

lewisjoe wrote: post #104
pavlov wrote: post #90

Earlier quoted context omitted.

> “No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives.” This is a massive change from my first software industry job in 1997. I was essentially a “design intern who knows HTML” on a team that built a shrinkwrap Windows application for enterprises. The core of the design team was a graphic designer, a cognitive scienti…

From a person who started using computers from the early 2000s era: THANK YOU! None of the current SaaS apps I use can come close to the experience of using softwares from that era. Take a simple list view of a typical Windows/Mac software? 1. Command clicking selected multiple objects 2. Shift clicking selected a range. 3. Right clicking brought up selection actions. 4. Double clicking opened an object. This pattern…

The problem isn't really with designers per se (tho they played a role). The problem is with the web as an application delivery platform - it was never designed for this.

Windows, or MacOS, both have design guidelines that was produced, and they expected native apps to follow. Most native apps do (the few that doesn't have either good reason, or were unique enough that their customers don't care - think photoshop).

With the advent of the web, such a guideline for software no longer mattered, because the controls and UI elements are all custom - since html is not an application GUI library!

So every man and their dog has a different UX and UI interaction built for their own app, because the web encourages it. The designers are also at fault for not standardizing on a set of common UI widgets, but i cannot blame them as this isn't the easiest path.

Re: Imaginary problems are the root of bad software

#280

Post by noisy_boy »

pdntspa wrote: post #193
ilyt wrote: post #127

Earlier quoted context omitted.

Remember times where you could change the theme and all of the apps followed suit ? Even in Linux there were tools to sync gnome with QT look so you could have one theme applied to every app for nice and consistent look, all the way to how the common icons look. Nowadays ? Every fucking app gotta have their own different styling. Will the setting icon be three dots, gear, or honey badger ? WHO FUCKING KNOWS. You'd be…

Even better, every app is doing their own styling so they can all look like Discord

Is it just me or there are others who find discords handling of threads terrible?! I mean Slack is far from my favourite but at least they treat a thread like a thread where I can see the entire conversation in one place instead of visually parsing questions and replies while frantically scrolling up and down.
Post reply on HN