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

201–210 of 511 posts

Re: Imaginary problems are the root of bad software

#201

Post by quickthrower2 »

pydry wrote: post #68
davidmnoll wrote: post #27

I agree with this to some extent. but there’s a flip side too. This mentality is often taken way too far. I had an old boss who wouldn’t allow me to write unit tests citing this thought process. Even at places with decent engineering practices, I’ve seen so many examples of software where you’re limited to a one to many relationship for something that could and easily should have been implemented as many to many, ren…

Ive seen a lot of engineers complain about YAGNI being taken too far but none who have seen their concerns validated by reality.

All depends on what the I is in the YAGNI. I have seen development be parallised where the same work is being done again and again by different developers in different ways because YAGN { maybe 2-3 days of upfront architecture and design for a 6 month project }. This results in bugs and maintenance nightmares. This was before unit tests were common though, so maybe unit tests may have saved it. But surely it was slower to develop that way.

But tautologically you can't take YAGNI too far, if the "YAGN" part is actually true :-). But that is always under debate.

Re: Imaginary problems are the root of bad software

#202

Post by throw10920 »

lewisjoe wrote: post #73

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…

They're not mutually exclusive.

FOSS software has vastly different incentives than commercial software, yet suffers from many of the same problems: bugginess, poor performance, lack of documentation, feature misprioritization, bad UI.

That alone indicates that the problem is not merely "misaligned incentives".

Actually, you can reduce most problems down to "misaligned incentives" if you're overly reductive enough. That doesn't mean that it's a useful way to think about the world.

Re: Imaginary problems are the root of bad software

#203

Post by eternityforest »

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.

Re: Imaginary problems are the root of bad software

#204

Post by astrobe_ »

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…

Not the first time the issue has been pointed out:

> Simplify the problem you've got or rather don't complexify it. I've done it myself, it's fun to do. You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you've got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the problem that you actually had.

[1] http://www.ultratechnology.com/1xforth.htm

Re: Imaginary problems are the root of bad software

#205

Post by vinyl7 »

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 of the architecture of the thing and so you're stuck with a slow weird ducktape solution to get around the 3rd party code's limitations.

Re: Imaginary problems are the root of bad software

#206

Post by ilyt »

bombolo wrote: post #181
ilyt wrote: post #131

Earlier quoted context omitted.

That's kinda what initally Go was made for IIRC. They noticed people which job is not programming but had to write some code (say some analytics or sth) often did it in Python, and if it was too slow they moved to C or Java and were predictably terrible at it, so that's why Go was made simple and with builtin concurrency primitives.

But his job is programming. He is very proud of his C skills. If you listen to him, it crashed because C is intrinsically bad (it is difficult yes), but I guess it was also such a bad codebase that rewriting it made sense. He also holds a grudge against me for having dared to rewrite a sacred C library he wrote (that was a constant source of segfault and I rewrote in 1 afternoon).

Sounds more like his job is producing tech debt. I saw few people like that, basically none of their code was left as most of that needed to be eventually replaced coz it was shit.

Re: Imaginary problems are the root of bad software

#207

Post by jakubmazanec »

pavlov wrote: post #90
lewisjoe wrote: post #73

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

Re: Imaginary problems are the root of bad software

#208

Post by whstl »

bombolo wrote: post #129
lewisjoe wrote: post #104

Earlier quoted context omitted.

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 with the controls is mostly because they don't want to pay for Qt (multiplatform toolkit), so instead every company (badly) implements their own controls in HTML to save money. I suspect ultimately they waste much more money than they save.

Qt isn't even in the radar of most companies currently building multi-platform applications in HTML. And it won't be soon, for two main reasons: developers able to use it are expensive, and most Qt applications in the wild still have the "uncanny valley" look and feel about them on every OS but Linux.

Not to mention that with SaaS being more profitable than selling unlimited-use licenses, a lot of apps also have HTTP backends and webapp versions, which can share a lot of HTML/CSS/JS code with a browser-based desktop version. Think of Slack/Discord/VSCode/etc. Sure: Qt, Flutter, etc also have web versions, but they just don't look/feel as good in the browser as an HTML app normally can.

If you want a "Premium" native look and feel, people gotta go directly to the source: native APIs. Qt won't do it without a lot of work. Lots of companies have separate Android and iOS teams. Or they go directly to HTML when there's not enough cash (or even things like Flutter, which look ok in mobile). High-quality macOS apps, like those made by Panic, Rogue Amoeba, etc, use Cocoa directly.

Standardized controls and shortcuts unfortunately end up being collateral damage in all of this.

Re: Imaginary problems are the root of bad software

#210

Post by chefandy »

jtriangle wrote: post #178
chefandy wrote: post #140

Earlier quoted context omitted.

I worked with a project manager that went too far in the opposite direction, though. Their pushback against premature optimization manifested in wanting to start with a functionalish "proof of concept" without any real design phase so they can say we cranked out an MVP in the first sprint... and before you know it, like most non-blocking technical debt, the "migrate functionality to final codebase" kanban card moves…

The trouble is, an 'MVP' is often far from 'minimum' in those sorts of situations. The reality is that MVP should be missing most planned functionality and should really just be a few core features and functions that the rest of the application builds off of, the trunk of the dependency tree so to speak. That idea is, unfortunately lost on the majority of PM's, and ultimately it costs more time/money to get to a fini…

It was actually the appropriate scope for an mvp, it was just an unreasonable time frame to make a solid codebase for anything other than a demo for the complexity of the project. That's fine for a genuine proof of concept/rapid prototype you're going to be disciplined enough to trash, but letting that slip into the role of your core codebase is like pouring a sloppy scaled-down concrete foundation as a test for a house, and then trying to just expand it into what you need.
Post reply on HN