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

161–170 of 511 posts

Re: Imaginary problems are the root of bad software

#161

Post by hinkley »

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 modern algorithms to classic designs and produce “hand tools” in software.

Re: Imaginary problems are the root of bad software

#162

Post by segh »

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'm not sure it's just incentives. Inexperienced early stage founders often end up solving imaginary problems, despite having a real incentive to get it right. The Y Combinator moto is "make something people want" because so many people don't.

Re: Imaginary problems are the root of bad software

#163

Post by jtriangle »

sirsinsalot wrote: post #100
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 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

Re: Imaginary problems are the root of bad software

#164

Post by [deleted] »

dagmx wrote: post #64
notatoad wrote: post #36

Earlier quoted context omitted.

i think you might be trying to solve the author's imaginary problems. all the author needs is a wordpress site with a couple plugins and a few weeks of back and forth on the design work. if you can't make a good profit on that with a $15k invoice, you're doing something very wrong.

The problem is that their brief is too vague and the real issue is communication. At no point is it clear that they’ve discussed off the shelf solutions, or infrastructure (storage, server hiding, CDN etc). If they had, then they either messed up because 15k over two months is too high or too low. It’s squarely in the: “nobody has actually defined the project territory” for me. Yes, a Wordpress solution would work, b…

[deleted]

Re: Imaginary problems are the root of bad software

#165

Post by rafark »

mikebenfield wrote: post #156
rafark wrote: 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.

Well, OK. But by that logic, if the language they had been most familiar with was Fortran, should they have used Fortran for Facebook? I tend to think that there are actually material differences between languages and technologies, and it's worth knowing more than one language and not using terrible ones.

“ But by that logic, if the language they had been most familiar with was Fortran, should they have used Fortran for Facebook”

Absolutely. Otherwise they wouldn’t have been able to release the actual product and keep adding features to it the way they did with Facebook. They’d spend half the time learning the “right” language & environment. That would have slowed them down to the point they wouldn’t have been able to work on the actual product as much as they did.

And feature-wise, Facebook evolved really quickly.

Re: Imaginary problems are the root of bad software

#166

Post by waboremo »

ilyt wrote: post #142
tetha wrote: post #18

Earlier quoted context omitted.

And people underestimate how well some solid, dumb solutions can scale. Boring spring boot with a decent data model and a bit effort to stay stateless scales to the moon. Or, we're having a grand "data export" system customers use to collect data from us for their own DWHs. It has survived 2 attempts at replacement so far. At it's core, it's psql + rsync, or was recently migrated to psql + s3 when we decomissioned ou…

> And people underestimate how well some solid, dumb solutions can scale. I'd say they underestimate how long "just throwing money" (servers) at the problem can work. If you earn decent money now, scaling number of app servers 10x times to serve 10x times the traffic will still earn decent money. Doesn't matter that "PHP is slow", deal with it when your infrastructure cost warrant hiring more/better developers to fix…

Even then, you don't have to throw money at the problem right away. If you feel you can save time and money by using Rust instead of PHP (just using the two languages as examples, not a specific indication of Rust or PHP's resource drain), go ahead. Making that decision early on costs nothing.

It's only after a project is off the ground that caring about these decisions winds up wasting everyone's time, that's when you wind up slowing momentum tremendously due to dangling a potential new toy in front of your team.

Re: Imaginary problems are the root of bad software

#167

Post by notatoad »

dagmx wrote: post #64
notatoad wrote: post #36

Earlier quoted context omitted.

i think you might be trying to solve the author's imaginary problems. all the author needs is a wordpress site with a couple plugins and a few weeks of back and forth on the design work. if you can't make a good profit on that with a $15k invoice, you're doing something very wrong.

The problem is that their brief is too vague and the real issue is communication. At no point is it clear that they’ve discussed off the shelf solutions, or infrastructure (storage, server hiding, CDN etc). If they had, then they either messed up because 15k over two months is too high or too low. It’s squarely in the: “nobody has actually defined the project territory” for me. Yes, a Wordpress solution would work, b…

>At no point is it clear that they’ve discussed off the shelf solutions, or infrastructure (storage, server hiding, CDN etc).

why should they? the requirements are listed in the article. the job is to meet the requirements. "where should we store the files" is a job the client hires you to answer, not something requiring communication.

Re: Imaginary problems are the root of bad software

#168

Post by jodrellblank »

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.

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?

What about insider trading laws? How can we say "share prices reflect all information" when we know there are people who have more information which would give them an unfair advantage, which means the current shareprice cannot be reflecting the information they have?

Re: Imaginary problems are the root of bad software

#169

Post by neon_electro »

tracerbulletx wrote: post #54
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…

This is why I think running a small business was the best thing I ever did for my software career.

How do you manage sales?

Re: Imaginary problems are the root of bad software

#170

Post by hinkley »

My venom for design patterns has risen over the years, and I think the reason is that Patterns always represent concrete architecture changes long before the last responsible moment.

In my code I tend to leave negative space. A spot where a feature could logically fit, without having to really design that feature before we need it. And as my comfort with compound refactoring has improved, some code smells have fallen off of my veto list. If we need to do X then this solution will stand in our way, but we can alter it here and here if that becomes a problem. It works well for a team of one, but it can be difficult to express in a code review, when someone is adding the fourth bad thing to the same block of code and now I’m pushing back for odd sounding reasons because my spidey sense is tingling about bridges too far.

Post reply on HN