Live data from Hacker News

Imaginary problems are the root of bad software

cerebralab.com

191–200 of 511 posts

Re: Imaginary problems are the root of bad software

#191

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 think of it in even broader terms: being/staying lean, re-using tried and tested things, adapting your requirements to widely available solutions rather than developing custom solutions to fit your requirements, making everything work more efficiently, etc -- all those resource-minimization issues are "less" problems: not good problems to be working on when your raison d'être is "more" -- and that's the only raison d'être for a lot of people and actually for all businesses. (Obviously there are also specialists for doing "less" "more": unsurprisingly, they are generally paid a cut of savings.)

Re: Imaginary problems are the root of bad software

#192
Ah yes. This explains very well why, when I ask our corporate IT for a static website with essentially text + some PDF downloads, I keep ending up in a “web platform” project based on a fiendishly complex CMS that is made for running large-scale e-commerce sites — of course delivered after ages and requiring multiple rounds with the CFO to justify the increased budget.

Been through that at several companies now.

Re: Imaginary problems are the root of bad software

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

Even better, every app is doing their own styling so they can all look like Discord

Re: Imaginary problems are the root of bad software

#194

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

[deleted]

Re: Imaginary problems are the root of bad software

#197
post #72
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…

Your guy clearly had an emotional attachment to his work not an inexplicable intellectual attachment. It's hard to admit that your baby is ugly.

This is one reason I’m glad I came from a research background into software. If something doesn’t work it doesn’t upset me and I don’t personally feel aggrieved, you just chalk it up to experience and move on. The number of times I worked on a study that had to be abandoned either because it didn’t work or because another research group beat us to it!

Re: Imaginary problems are the root of bad software

#198
post #12

Earlier quoted context omitted.

I believe Saying simple > complex doesn’t actually mean anything because it’s effectively impossible to pin down definitions. They are totally in the eye of the beholder. Solutions that are simple in one axis almost always trade of complexity in other axes.

As a good illustration, consider FEniCS[1], where you can write a few lines of Python code which looks almost exactly like the math you're trying to solve, and have it compute the answer. Very simple! Except to make that work there's a lot of infrastructure, including runtime-generated-and-compiled C++ code that gets dynamically loaded by said Python code to perform the actual calculations. Quite complex! The true sk…

I’d argue that FEniCs was a prime example of this in some ways, at least earlier in it’s history.

I started using it in about 2014. It was not exactly what I would call a simple project. It used to be an ordeal to build, could only easily be used via Docker, ported to Python 3 a long long time after most of it’s dependencies did, had an unstable C++ API that changes were not documented for but nonetheless you were required to use if you wanted for reasonable performance for some calculations, etc. The national supercomputing centre in my country managed to only get one version to build because it was so poorly specified at the time and basically only supported Ubuntu!

FEniCsX is considerably better usability wise, but that’s the result of hard lessons learnt.

Re: Imaginary problems are the root of bad software

#199

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…

As a team lead, I’ve found it really difficult to keep curious, smart, young engineers on track. Everyone wants to go off and build shiny things instead of solving real problems. I have to find enough shiny problems that actually need solving to balance out the daily grind. Interestingly, I also find it difficult to instill a sense of meticulousness, and how important it is to write code in a way that reduces bugs. Clever engineers come up with clever, complicated solutions that are written quickly and rely on coincidence to function. Life experience is the best teacher for this, but I often need to step in. I’m still not sure what the balance is there.

Re: Imaginary problems are the root of bad software

#200
post #86

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 really think we have too many people working at most companies. It pushes people to the extremes and edges just to have something to work on. Managers need more people under them to get promotions. And managers want to manage managers to keep moving up. They fill teams of people on products that could really be ran by a fraction of the engineers. But that’s not where we are, we are on large teams working on small a…

> we have too many people working at most companies.

I half-disagree with this. My take is significantly more top-down: senior management has a deficient concept of how product development works. They believe Manpower is to be spent to achieve revenue, either by directly selling the result as a product (e.g. airplanes selling wifi to passengers) or by it being a differentiating feature for the sales department. This causes every allocation decision (like hiring) to fundamentally be biased around getting a tangible return: by creating new projects, new features, and new buggy microservices.

Further, since management only has two knobs (manpower and timeline) to play with, they like to move them to feel like they're optimizing the project. It's always the same fallacies, too: "we hired more people so we can create explosive growth", "we created ambitious timelines, now we're striving to fill them" etc.

I don't have a solution for this, except to note that it can be mitigated by managing up. Construct your own narrative, and take advantage of the fact that the non-technical people above you govern almost entirely by gut feeling.

Post reply on HN