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

181–190 of 511 posts

Re: Imaginary problems are the root of bad software

#181

Post by bombolo »

ilyt wrote: post #131
bombolo wrote: post #126

Earlier quoted context omitted.

Coworker of mine wrote a thing in java… it was too slow (intensive locking between threads)… so he rewrote it in C… it was crashing all the time (because he sucks), then he rewrote it in go. Got promoted for this feat.

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

Re: Imaginary problems are the root of bad software

#182

Post by evandale »

lewisjoe wrote: post #111
lfowles wrote: post #106

Earlier quoted context omitted.

Those four actions worked for me on the Google Drive web interface

Great! Now try it in any other list view in any other app. Maybe the list of docs in https://docs.google.com ?

On my phone so it's hard to check, but Gmail's ctrl and shift clicks work really well and is intuitive to me. I'm shocked they wouldn't use the same mechanics everywhere.

Best example: Gmail is one of the only webapps I'll ctrl click a few items at the top of the list, ctrl click a few in the middle, and then shift click to the bottom and it works exactly how I'd expect - everything stays selected and the shift+click selects from your previous click to the next item. I think it gets wonky if you change directions but I can't imagine how I'd expect ctrl+click item 1, 2, 9, 10, then shift click on 4 would work.

Re: Imaginary problems are the root of bad software

#183

Post by sh34r »

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…

I agree with just about everything you've said, except that bit about rewrites. Rewrite projects typically go down in flames, and on the rare occasions that they don't, the business stakeholders are still mad because their precious feature factory was down for maintenance for months.

Re: Imaginary problems are the root of bad software

#184

Post by elcritch »

spencerchubb wrote: post #30

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

Easy, banking and especially banking software is not an efficient market.

Re: Imaginary problems are the root of bad software

#185

Post by pydry »

davidmnoll wrote: post #175
pydry wrote: post #144

Earlier quoted context omitted.

>I had a boss refuse to let me do a refactor that changed these sketchy dynamic field tables into json columns because “it’s not customer facing YAGNI isnt about not refactoring existing technical debt. It's about not trying to pre-empt future requirements. If youre refactoring in anticipation of as yet unmaterialized requirements then YAGNI applies - e.g. generalizing code when when today there is 1 specific use cas…

All of these definitions are fuzzy... refactor versus upgrade versus feature. When the people wrote it the way they did, they were almost certainly thinking that they don't need to overthink or over-engineer, and that they should discount hypothetical future concerns. I can give you an abundance of examples. We were creating a page that was going to use state in a certain way. I was trying to insist that we address t…

>I can give you an abundance of examples. We were creating a page that was going to use state in a certain way. I was trying to insist that we address the way state will be handled across pages ahead of time. These concerns were dismissed as premature optimization. A few months later we had 5 pages with the state being handled in 5 different ways.

The right time to address this was probably a bit at a time after the 1st, 2nd and 3rd pages. Certainly not before the 1st and definitely not after the 5th.

>All of that could have been avoided by spending 1 day thinking a little harder and planning for the future.

The reason why you try as hard as possible to avoid planning for the future is because it's really hard to predict the future. Moreover humans have an inbuilt bias towards thinking we are better than we are at it (hence the gambling industry).

Refactoring as soon as possible after the fact will always produce better designs than up front planning for this reason.

>there are regular ways that programs grow based on how the business is growing and you can predict certain places

This is the kind of phrase that makes alarm bells go off in my head that somebody SHOULD be following YAGNI and isnt.

If it's defaults in a well worn framework that doesnt railroad you then fine but anything more than that - red flags all around.

Re: Imaginary problems are the root of bad software

#187

Post by dagmx »

totallywrong wrote: post #120
dagmx wrote: post #17

I know it’s just an arbitrary number picked but this bit jumped out at me: “You’ve just wasted $15,000 on two months work with a team of contractors” The project may also have been doomed because $15k is not very much for something like they described. But again, fully aware that they probably picked a random number. I’d have just added another zero to make it more realistic.

15k is rather high for those specs. A single competent dev can build that in a month.

15k for a single dev over a month, sure. 15k for a team over multiple months is different though.

Re: Imaginary problems are the root of bad software

#188

Post by analog31 »

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…

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.

Re: Imaginary problems are the root of bad software

#189

Post by Aerbil313 »

hinkley wrote: post #161
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…

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.

Re: Imaginary problems are the root of bad software

#190

Post by nicoco »

ilyt wrote: post #127
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…

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 in Linux there were tools to sync gnome with QT look

There are still such tools, you don't have to use the past tense here.

Post reply on HN