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

361–370 of 511 posts

Re: Imaginary problems are the root of bad software

#361

Post by disgruntledphd2 »

fauigerzigerk wrote: post #79
tyingq wrote: post #51

Earlier quoted context omitted.

HipHop (later HHVM) was around 2010, so they scaled from 2004-2010 before that became needed. MyRocks was 2015. Wikipedia says FB was around 300 million users in 2009, then 400 million users in 2010.

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.

It was much, much, much cheaper than a rewrite would have been, that's why they did it.

Edit: also, in 2004 when they got started, what else could they have used?

Re: Imaginary problems are the root of bad software

#362

Post by civilized »

The species of this I most commonly encounter, and IMO the most illuminating of the issue, is Solution in Search of a Problem. People love having a solution to a problem so much, they will hallucinate the existence of the problem the solution is for. Especially when social approval has replaced any actual mission of the org.

In other words, when you have a hammer, everything looks like a nail.

Re: Imaginary problems are the root of bad software

#363

Post by liftsh »

Cthulhu_ wrote: post #351
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've been working in consultancy for most of my career and have been in so many projects by now that seemed to be bullshit rewrites in $tech of the month; at least two projects where microservices were pushed through. The last one I was in was funny because while they had a small army of consultants and self-employed engineers vying for influence and carving out their own slice of the pie, the existing team of runnin…

New is not always better, but many times it is. We see this for example in programming languages, where newer ones incorporate the best features of their predecessors.

I think there are two things to be wary of: 1) Selecting a new technology just because it's hot, and 2) Refusing to consider new technology because the old stuff "just works." A good engineer looks at the requirements and selects the best tool to solve the problem while weighing the costs and benefits. Sometimes that's microservices. Sometimes it's monoliths. Granted, I don't know anything about the developers or business problems at that company, but to say that Scala microservices are just bad without justification doesn't sit right with me. It's all situational.

If an engineer comes to me and asks to use something like Scala, he'd better know all the upsides AND downsides (e.g. effect and streaming abstractions, ease of long-term maintenance, referential transparency, vs learning curve, hire-ability, 100 different ways of doing things, etc).

Re: Imaginary problems are the root of bad software

#364

Post by Aperocky »

djmips wrote: post #247
Aperocky wrote: 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

It need to be thrown around more. I cannot count on one hand the designs I came across that were needlessly complicated that rather than solving a pain point became a problem in themselves.

Re: Imaginary problems are the root of bad software

#365

Post by strulovich »

liftsh wrote: post #363
Cthulhu_ wrote: post #351

Earlier quoted context omitted.

I've been working in consultancy for most of my career and have been in so many projects by now that seemed to be bullshit rewrites in $tech of the month; at least two projects where microservices were pushed through. The last one I was in was funny because while they had a small army of consultants and self-employed engineers vying for influence and carving out their own slice of the pie, the existing team of runnin…

New is not always better, but many times it is. We see this for example in programming languages, where newer ones incorporate the best features of their predecessors. I think there are two things to be wary of: 1) Selecting a new technology just because it's hot, and 2) Refusing to consider new technology because the old stuff "just works." A good engineer looks at the requirements and selects the best tool to solve…

If new is not always better, then you’re stuck with the really hard job of knowing when it’s worth moving to the new thing.

Worse, you’ll be blinded by survivability bias. One easily notices the good rewrites and can easily ignore the bad ones.

Even worse, bad rewrites may be noticed in a place that a year or two ago was deemed a success story. I’ve seen many such cases due to misunderstandings or just political dynamics.

And lastly, don’t let that Engineer do Scala, they’ll brush off the compilation time regression and make all developers lives slightly worse (assuming the project is big enough)

Re: Imaginary problems are the root of bad software

#366

Post by whstl »

wruza wrote: post #261
sirsinsalot wrote: post #100

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…

For that to happen, two things must match: a product guy who knows your job and you who know how to make products. It doesn’t even have to be stable/featureless, in my experience. New developers tend to worship some new paradigm that focuses on “how” instead of “what”, which is all paradigms can do. And once they’re in, it goes downhill because the how dominates the what. Add a clueless product guy into the mix and i…

I'm not GP but I'm in a similar situation, and yeah, this is how I do it.

My Product Manager is competent both in technical and product/design matters and is also able to call BS on complexity for complexity sake. I ensure that the development part is focused.

New developers have to prove with technical and business arguments any new paradigm or random refactoring they want to do. If there is no immediate need, we just skip it.

Re: Imaginary problems are the root of bad software

#367

Post by andsoitis »

bambax wrote: post #300
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…

Also: CTRL+A selects all CTRL+Shift+End selects all from where you are to the end CTRL+Shift+Home selects all from where you are to the top One of the (many) problems of web UIs is they often ignore the keyboard completely.

Emacs would like to have a word.

Re: Imaginary problems are the root of bad software

#369

Post by balder1991 »

vbezhenar wrote: post #77

How do you manage boring part though? Going mad because of boredom is a real thing. I definitely agree that some of my job is caused exclusively by my need to keep myself entertained. But what's the solution? Another factor is resume driven development. Yes, you can frown upon it all the day, but in the end I'll switch company and I'll need to find a new job. And, like it or not, but everyone these days wants a lot o…

I do it by building side projects. As they’re purely experimental, I can use whatever I want and learn a ton.

Re: Imaginary problems are the root of bad software

#370

Post by Denzel »

Aeolun wrote: post #264
sanderjd wrote: post #259

Earlier quoted context omitted.

Yeah I dunno, I hear this a lot, but there has universally been way more work to do than people to do it at every company I've worked for. But that doesn't mean the right things are being prioritized.

There is a lot of work, but a lot of that work is generated by people doing the wrong thing too often. If we had a smaller and more competent team, the initial build might have been marginally slower, but we wouldn’t have to spend a permanent 50% to just keeping down the technical debt.

You’re working from a cost-efficiency / cost optimization perspective. That’s a great perspective in some contexts, for example, mature late-stage products, fully saturated markets, etc.

Is cost efficiency an effective perspective for innovation or revenue growth? Mostly, no. As long as your risk-of-ruin is low, then you want to fail. Sometimes people misinterpret this as “doing the wrong thing”. But it takes doing a lot of wrong things to do the right thing.

The difference between right and wrong, if there ever was such a simple dichotomy, is so marginal and only understood in hindsight.

Post reply on HN