Reckless Software Construction(blog.sidstamm.com)
blog.sidstamm.com
Reckless Software Construction
https://blog.sidstamm.com/2021/12/reckless-software-construction.html
9 comments
> Demand for rapid development of software has radically changed how we develop, deploy, and maintain software over the past decade or so.
Same as it ever was. We do the best we can with what we have.
> Agile and rapid iteration allow fast-to-market delivery.
This is how I know you're making a marketing post.
> The equation is simple: moving fast and cutting corners leads to increased risk. > Stop it. Be an engineer, not MacGyver.
An engineer makes tradeoffs. Risk is one factor among many, which developers have to consider.
> Dear software developers: please please please stop making disposable software.
All software is disposable. So, no.
Same as it ever was. We do the best we can with what we have.
> Agile and rapid iteration allow fast-to-market delivery.
This is how I know you're making a marketing post.
> The equation is simple: moving fast and cutting corners leads to increased risk. > Stop it. Be an engineer, not MacGyver.
An engineer makes tradeoffs. Risk is one factor among many, which developers have to consider.
> Dear software developers: please please please stop making disposable software.
All software is disposable. So, no.
I was going to post some of what you did but not as well.
I'll just add that the reward is greater than the risk. And the author's shaming doesn't make it any less rewarding.
I'll just add that the reward is greater than the risk. And the author's shaming doesn't make it any less rewarding.
From a comment on the original post:
> I think this is a great post and I agree with many of the points, but I'm not sure if the people reading this would be in a position to do anything about it. There will always be pressure from upper management to get software out as quick as possible to build the highest margins possible. If this means not researching all of your dependencies, or not documenting the dependencies properly, those will be the first to go.
> I think this is a great post and I agree with many of the points, but I'm not sure if the people reading this would be in a position to do anything about it. There will always be pressure from upper management to get software out as quick as possible to build the highest margins possible. If this means not researching all of your dependencies, or not documenting the dependencies properly, those will be the first to go.
Yes. Ownership of questions like "Are you building the right thing?" is explicitly delegated to product managers/owners/whatever the fuck they're called at your company. Software engineers have almost no say over that. If you speak up, nothing will happen.
The app being 270 MB and requiring updates every week is the result of following "best practices." If you question those practices or suggest alternatives, you will be told bullshit about "operational maturity matrices" and other bullshit that actual users don't care about because it doesn't make the product any better.
Don't bother. If you want to make good software, you either have to do it as a side project of your own, contribute to a high quality open source project, or start your own company.
The app being 270 MB and requiring updates every week is the result of following "best practices." If you question those practices or suggest alternatives, you will be told bullshit about "operational maturity matrices" and other bullshit that actual users don't care about because it doesn't make the product any better.
Don't bother. If you want to make good software, you either have to do it as a side project of your own, contribute to a high quality open source project, or start your own company.
Push back. If upper management only allows you to build rushed badly-documented hard-to-maintain tech-debt-ridden software, if upper management doesn’t care about the user but only about maximizing margins, change jobs. Do you really want to spend your working life churning out crap software?
Sorry about the hyperbole, but caving in to bad incentives is what brought us into that situation in the first place. Upper management couldn’t build anything if not for the software engineers.
Sorry about the hyperbole, but caving in to bad incentives is what brought us into that situation in the first place. Upper management couldn’t build anything if not for the software engineers.
Why? It's just going to be the same shit everywhere else, except now the timer on your RSUs is reset.
Sadly we live in times of capitalism's perverse incentives.
Managers push hard to get one more "win" on their CV before skipping onto the next higher paid job. The company board are only interested in maximising "shareholder value" and their already bloated remuneration packages.
Developers are still evaluated on the basis of LoC! If you want your job and a chance at a bonus, then you just do as demanded by the bosses.
Managers push hard to get one more "win" on their CV before skipping onto the next higher paid job. The company board are only interested in maximising "shareholder value" and their already bloated remuneration packages.
Developers are still evaluated on the basis of LoC! If you want your job and a chance at a bonus, then you just do as demanded by the bosses.
The author seems to make good points but they lack risk assessment intelligence. Software security’s risks are technically challenging to exploit and require law breaking. If you’re working for a crypto exchange, then maybe this is an issue for you.
Even in that case, it’s way more likely that someone will fall for spear phishing then importing a JS library would result in being hacked. It’s important to consider the statistical likelihood that your vulnerability will be exploited when considering security.
Even in that case, it’s way more likely that someone will fall for spear phishing then importing a JS library would result in being hacked. It’s important to consider the statistical likelihood that your vulnerability will be exploited when considering security.
This “MacGyver” mindset over an engineering mindset is a core problem with most devs I work with.
Nobody takes the time to understand fundamentals, theory, or engineering principals. They copy-paste and flail around until it works, and aren’t even curious to learn why.
But the problem is, software dev culture seems to embrace and celebrate this MacGyverism.
Look at all the memes about how software devs’ job consists of copying from Stack Overflow for a living, or how they have no idea how their app is even working, or any number of memes that reduce software development to wizardry - but not the “Hogwarts, study and master it” wizardy, but instead the “I accidentally spilled the glowing purple vial on a frog and created a lizard person” kind of wizardry.
I do think software development has room for, and even requires, both true engineering work AND “super user”-type developers, especially as low code tools help make things more accessible. I also think almost anyone can learn an engineering mindset if motivated to do so.
So I’m not trying to gatekeep, in fact I’m happy if my job becomes building the tools that help the super-user-devs fumble their way to success.
But I also am very much concerned with the industry’s joyful conflation of purposeful engineering with fumbling tinkerer as though they are one and the same, and as though being the fumbling tinkerer is all that should be expected of all developers, all the time.
At some point, we need to return to teaching and promoting the value of learning fundamental principals, and of building a solid, well-engineered, well-documented product that works because it was built to work, and not because “I don’t know but if I paste this here and that there then it seems to be fine”.