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…
Imaginary problems are the root of bad software
191–200 of 511 posts
Re: Imaginary problems are the root of bad software
#192Been through that at several companies now.
Re: Imaginary problems are the root of bad software
#193Earlier 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…
Re: Imaginary problems are the root of bad software
#194Earlier 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
Re: Imaginary problems are the root of bad software
#195Re: Imaginary problems are the root of bad software
#196Re: Imaginary problems are the root of bad software
#197I 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.
Re: Imaginary problems are the root of bad software
#198Earlier 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 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
#199If 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…
Re: Imaginary problems are the root of bad software
#200If 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…
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.