The growing complexity of modern software systems is slowly killing software developers. How can you regain control, without losing out on the best these technologies have to offer?
Why make something better than it needs to be? I like overengineering just as much as the next girl, but in software you throw away your stack every few years anyway. It’s rare you can write any software that lasts a decade without maintenance, often the “bad software” is only bad because nobody maintains it. The initial/release state of the software is irrelevant, the problem arises when nobody is around to fix the issues. Which, in turn, is of course a confirmation of your initial argument:
a lot of the problems stem from capitalist mode of software production
How can one fix this? What can singular people do to stop others from needlessly introducing complexity into software which is bad to maintain in the first place?
This has nothing to do with overengineering. What I’m talking about are development practices and problems such as rushed delivery, underspecification, development is driven by marketing, lack of time for refactoring, and so on. All of that stems from companies wanting to cut corners and rush their software to deliver as quickly and cheaply as possible.
When software is developed without the constraints of business, then developers can take their time, think things through, and move at a sustainable pace.
Another thing I’ve noticed in places I’ve worked, is that either management, or self-serving devs will intentionally not use open standards and FOSS tech, which makes it that much more difficult for new devs to understand what’s going on. By reinventing the wheel hundreds of times, they can make themselves irreplaceable, or management can justify long-running projects. Such a waste to see dozens of people with pretty much the same problem, not collaborating, but solving it repeatedly on their own, all in the name of competitive profit-seeking.
I’ve heard it said that really good coders will code themselves out of a job, and its true… yet another contradiction of capitalism.
Why make something better than it needs to be? I like overengineering just as much as the next girl, but in software you throw away your stack every few years anyway. It’s rare you can write any software that lasts a decade without maintenance, often the “bad software” is only bad because nobody maintains it. The initial/release state of the software is irrelevant, the problem arises when nobody is around to fix the issues. Which, in turn, is of course a confirmation of your initial argument:
How can one fix this? What can singular people do to stop others from needlessly introducing complexity into software which is bad to maintain in the first place?
This has nothing to do with overengineering. What I’m talking about are development practices and problems such as rushed delivery, underspecification, development is driven by marketing, lack of time for refactoring, and so on. All of that stems from companies wanting to cut corners and rush their software to deliver as quickly and cheaply as possible.
When software is developed without the constraints of business, then developers can take their time, think things through, and move at a sustainable pace.
Another thing I’ve noticed in places I’ve worked, is that either management, or self-serving devs will intentionally not use open standards and FOSS tech, which makes it that much more difficult for new devs to understand what’s going on. By reinventing the wheel hundreds of times, they can make themselves irreplaceable, or management can justify long-running projects. Such a waste to see dozens of people with pretty much the same problem, not collaborating, but solving it repeatedly on their own, all in the name of competitive profit-seeking.
I’ve heard it said that really good coders will code themselves out of a job, and its true… yet another contradiction of capitalism.
Yeah, I’ve seen lots of homegrown solutions that could’ve been easily replaced by off the shelf open source projects as well.
Related post: https://drewdevault.com/2021/10/17/Reliability.html