Live data from Hacker News

Imaginary problems are the root of bad software

cerebralab.com

151–160 of 511 posts

Re: Imaginary problems are the root of bad software

#151
post #56

This resonates and one way to describe it is an incentive problem. Someone whose incentives are tightly aligned with the business is going to solve the actual problem and simply and effectively as possible. Someone who is incentivized to build career capital and experience other than via impact (e.g. so they can get uplevelled, pass an external interview loop, etc) is much more likely to focus on unimportant hard pro…

RDD: Resume Driven Development

This is absolutely a thing, but I'd say there's a related option which is "Job Listing Driven Development". The more niche, dated, or specific your platform is, the harder it is to hire people onto the team who don't need months of on-the-job practice and training to be useful.

You see the most extreme versions of dangers of this in stories about governments and older companies having to pay insane salaries to bring FORTRAN or COBOL developers out of retirement to keep systems running. If you keep doing the simple solutions within the existing system, you risk creating a system so inbred that only the folks who built it can maintain it effectively.

For less extreme setups, it's still a balancing act to consider how much your unique and specific solution that is the simple option for you company starts closing you off of the larger hiring pools in more common technologies and patterns.

Re: Imaginary problems are the root of bad software

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

Now you have a whole bunch of New SQL databases that will scale past whatever number of users you can imagine. So your good old Django or Rails app can scale to 1M or 10M users without you doing anything exotic. That's not "fun" though.

Re: Imaginary problems are the root of bad software

#153

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 don't know, the more I advance in my career, the more I see it as the opposite. Wide eyed developers with big designs, who are obsessed with the technical aspects of a solution, who disregard the practicalities, long term implications at the social level (who is going to maintain this, do we have people that have that skillset, is this worth the effort, does it really matter to be this elegant, or is it more import…

The problem for a lot of the social level issues is that it is pure pure politics.

Re: Imaginary problems are the root of bad software

#154
I spend a lot of time saying “I told you so” to people who were sure my problems were imaginary. When you don’t stay somewhere long or you have a short time horizon it’s hard to connect cause and effect. Also pretending uncomfortable things don’t exist is a very popular character trait.

It’s not impossible that some of the problems I see others manufacture have a genesis in past traumas they are trying to avoid (some coping mechanisms are healthier than others).

Re: Imaginary problems are the root of bad software

#155
post #143

Earlier quoted context omitted.

So I think the interesting question is whether the rest of us can learn anything from what happened there. I believe Mark Zuckerberg simply used the technology he knew and took it from there. That's fine. I probably would have done the same thing. But many people are making an ideology out of this, arguing that not giving a shit about performance is always the right choice initially because that's how you grow fast e…

Learn what? That you should use the language that you’re more comfortable with and then scale? Or that languages have become more efficient? Php 8, for example, is many times faster than the php 4 and 5 that Facebook was using.

I think using what you already know remains a choice that is very hard to criticise. But we didn't have to learn that, did we?

Beyond that I think there is more to unlearn than to learn from the history of the Y2K batch of startups. The economics of essentially everything related to writing, running and distributing software have changed completely.

Re: Imaginary problems are the root of bad software

#156
post #145
post #135

Earlier quoted context omitted.

Did they succeed because of PHP or was it just a tech used at the time and anything else similar at the time would be fine either way?

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.

Re: Imaginary problems are the root of bad software

#157

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…

Sounds like a dodged bullet.

Re: Imaginary problems are the root of bad software

#158
post #146

Earlier quoted context omitted.

Yes, good point. But you have to wonder what kind of engineering effort went into scaling PHP and MySQL up to the point where they decided to build a compiler and a storage engine.

When you have half a billion users that both read and write all day, you have to optimize, no matter the tech.

That is undeniably true, but I do think the starting point still matters.

Re: Imaginary problems are the root of bad software

#159
post #55

I absolutely agree with the premise. People just love building things even when they're not needed. After a while, your ego gets attached to whatever it is you've built and you can't let it go. I remember working at one place where somebody built a new framework to solve a common problem we all had. He pitched it to all the other devs in a meeting and I remember being confused about it because there was a standard fr…

> people are just unable to see simple solutions to problems

This person might just have been terrified of admitting that all the (very tangible) time they spent on payroll building this thing was for naught. It’s unclear how their manager might have responded to that. And they wouldn’t have been able to put „built system doing X used by Y developers and deployed to Z customers“ in their resume.

The reasonable choice often doesn’t have much skin in the game.

Re: Imaginary problems are the root of bad software

#160

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…

This kind of problem surfaces in a large amount of systems involving humans and roles.
Post reply on HN