Live data from Hacker News

Imaginary problems are the root of bad software

cerebralab.com

241–250 of 511 posts

Re: Imaginary problems are the root of bad software

#241

Earlier quoted context omitted.

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

Minimal change, or minimal code? Refactoring code can make code smaller but depends on good testing. Applying minimal changes results in redundant and complicated code, but less likely to break existing functionality.

In the first instance, both. However, i'd take more code that was better reasoned and easily understood over less verbose code that was smaller for smaller sake.

In terms of minimal change, we refactor when there's a clear business case to permit taking on the risk. Otherwise, we make the most minimal, most stable, least risk change to the existing code even if that code isn't optimal/pretty/well-structured/has-errors/...

Like most other engineering in the world really.

Re: Imaginary problems are the root of bad software

#242

Earlier quoted context omitted.

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

Bless you man, you're doing the lords work

It ain't much, but it is honest work ...

... and well paid.

Re: Imaginary problems are the root of bad software

#243
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…

> Solving real problems for real people is very addictive.

This was the feedback loop that worked best for me. imaginary problems and needless complexity go hand in hand, ruthless editing at the planning stage is necessary to combat it.

Re: Imaginary problems are the root of bad software

#244

Earlier quoted context omitted.

Reminds me of a PM I used to work with. "Will this work for 1000 simultaneous users?" After almost 2 months, we have less than 100 users total, maybe 5 of them log in a day, and maybe 1 will actually do anything of interest. There is no technical problem. The problem is nobody worked on actually marketing the product. Build it and nobody shows up is the norm.

I was interviewing with a company that had barely any customers and they were asking scaling questions with Spark, etc. The salaries they paid could barely hire a team capable of dealing with the complexities of Spark, so they asked, "what would you do." I told them I'd buy another stick of RAM and scale vertically until I had more customers, and save money on staff in the meantime. The interviewer went cold, I didnt…

About 10 years ago, I worked on a project where I had to develop some sort of elaborate chain of map/reduce jobs because "big data" and "Hadoop." We were processing about 10 megabytes for each run. Most of the processing was consumed in job scheduling / overhead.

Re: Imaginary problems are the root of bad software

#245

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…

You can still get away with these things if your only user is yourself or maybe a small handful of non-enterprise folks. This could be why the so called "scientific" programmer feels like they can be as productive as a team of 10+ software developers. And also why the most frequent request from the users is: Please don't change anything. The principal-agent problem looms large in software.

"And also why the most frequent request from the users is: Please don't change anything."

I think it is: "Please don't change anything I did not request"

(who does not hate updates that break your workflow?)

But they usually very much like changes, that makes life easier for them. Best way to find out, is to watch them using your tool and talk with them.

Re: Imaginary problems are the root of bad software

#246
post #127
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…

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…

> Will the setting icon be three dots?

Multiple hamburger menus with a scattering of cryptic icons stuck at arbitrary places on the screen. What does the swirly icon with up arrow do? No text label for you!

Oh and let's move the next button to the top left of the screen and not highlight it. Mmmm that's some good UI design.

Re: Imaginary problems are the root of bad software

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

People need to stop throwing around 'Premature optimization is the root of all evil'. Simple > Complex <--- Look at that. It's optimization! Complex != optimized

Re: Imaginary problems are the root of bad software

#248

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…

Definitely.

I’ll say one thing though: all of those skills you mentioned as not being valued are extremely useful for indie dev/taking ownership. Shipping simple + correct code frequently is extremely possible with sufficient practice and discipline.

More to your point, this is why I switched toward being a research engineer. There is a higher barrier of entry, projects are quite technically challenging, and constraints often force thinking of a world of computing beyond the tiny sphere of the web browser.

It’s hard work, but I love it.

If this resonates, you are in the US, and looking for a change, drop me a note (see profile).

Re: Imaginary problems are the root of bad software

#249
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…

Oh man I totally forgot about that. Thank you for the reminder. Total flashbacks to windows 95 and every so often changing the windows color, text font etc. for the entire system Good times

A lot of native apps on iOS still at least follow the light/dark theme and global font sizes. But I’m not sure if that works by default with Flutter or React Native etc. or if they’d have to implement it explicitly.

Re: Imaginary problems are the root of bad software

#250

Earlier quoted context omitted.

There’s a couple of woodworking hand tool companies who among other things make replicas of old school Stanley tools, the way Stanley used to make them (materials and tolerances). They also fuse the best elements of several eras or manufacturers to make slightly better versions. Surfaces from this one, handles from that one, adjustment mechanism from a third. I hope that I live to see a time when software applies mod…

The field of software is maturing as we’re reaching the end of Moore’s Law and time passes. Times of constant innovation is very slowly coming to an end, the curve is slowly flattening. You can already see it with general trends like type-safety, DX features universal in all languages (linting etc.), browsers finally becoming the universal OS (Wasm, WebUSB, GPU), more and more things being standardized every day.

Proebsting's Law says compilers double code efficiency every 18 years. I wonder what the doubling interval is for algorithmic performance. I expect it would be tough to calculate, like the cost of living, because algorithmic improvements rarel affect all aspects of code performance equally. Incremental improvements in sorting efficiency likely have one of the broadest reaches, followed by concurrency improvements and object lifetime analysis. Then there's a long tail of niche applications that only apply to certain domains. Only the Amdahl's Law parts of the code has a substantial impact on performance.
Post reply on HN