3 ms·

This is mostly just a rant not directed at you but on the state of software... The Colonial Pipeline ransomware wasn't life threatening. These things happen be

by Dah00n 5y ago

This is mostly just a rant not directed at you but on the state of software... The Colonial Pipeline ransomware wasn't life threatening. These things happen because of bad* developers and zero accountability from developers over publishers to software owners. As it is now pretty much all commercial software is "first time waiter" quality. Granted it isn't all on the actual developers but on the whole pipeline(!). Most software is on the "let's use an anchor to stop our newly developed car because we have used anchors for decades and understand them better than drum brakes" level of quality. * Bad code because of a lack of understanding and/or time constraints. But developers don't mind coding bad code (not enough to refuse at least). Developers need to be more like doctors and engineers. Accountability and proven skill matters and would force managements hand like at hospitals and building projects.

gombosg 5y ago
I'd like to add that modern agile IT environments are different than that of traditional engineering. We aim for fast MVPs, fast iterations, "failing fast", "moving fast", "delivering value quickly", generally preferring speed over quality, agility over "waterfall" planning, continuous delivery over batched releases and, well, often accruing tech debt over shipping features later. One can argue that "fail fast" should not be about code & feature quality but rather about determining proper scope, splitting features sensibly etc. But then we still have deadlines to meet and code quality suffers. What I'm saying that this kind of fast-moving environment actively discourages traditional (like doctors & civil engineers) engineering practices. You might have lots of (unit|integration|E2E) tests but the company may miss practices like proper security reviews and code won't be reviewed, tested and approved by multiple people like, say, bridge building plans are. This problem mostly comes up not with your usual web app but when critical systems are affected (like in the aerospace industry or industrial systems). But through supply chain attacks, nearly any system can be vulnerable these days. We should definitely have better regulation on how software is made.
- wongarsu 5y ago
  The problem with the waterfall model is that it only works if you can determine the requirements up front and they stay fairly static. Sometimes that's true, but all too often its impossible. But iterative development and fail-fast are independent of quality. If a company skips security reviews and is fine with technical debt because "it works, just ship it", what makes you think they would do security reviews or care about better-than-minimum code quality when following a waterfall system
runawaybottle 5y ago
Bad code is happening for non-malicious reasons. I’ll suggest these two being the main factors, and I’ll concede that it is conjecture, but I’m drawn to these two since I assume good-faith amongst all actors: 1) Everyone needs to pump out all of their bad code before they get to their decent code. Imagine your lifetime array of code, it will look like this [bad, bad, ...(lots of bad), bad, good, bad, good, good, ...(lots of good), good]. As you can see, you’ll have to pop (poop) all the bad out before you get to good. Some people have a smaller length array due to other factors (talent), but even so, there is bad in front of the array. What are the implications of this? That should be obvious. This industry hires people straight out of college or people in their mid 20s to be project leads. You do the math. 2) Lack of suffering. Many people haven’t had to toil in someone else’s codebase. Many people are given green-field projects that are scrapped quickly, at which point the business (or another business) gives a brand new project. Constantly building shit from scratch by yourself means you don’t understand pain. Go work in someone else’s garbage app to feel pain. Then you will rethink what good code is. Good code is not painful, and the definition of ‘not painful’ will be obvious to the survivors of pain. Solution: Continue to crap out your bad code in non impactful areas of the codebase and avoid crapping in critical parts. You have to crap somewhere, and that is understandable. Lastly, don’t turn down the experience of working in someone else’s labyrinth. The experience is valuable.

by Dah00n 5y ago

gombosg 5y ago

I'd like to add that modern agile IT environments are different than that of traditional engineering. We aim for fast MVPs, fast iterations, "failing fast", "moving fast", "delivering value quickly", generally preferring speed over quality, agility over "waterfall" planning, continuous delivery over batched releases and, well, often accruing tech debt over shipping features later. One can argue that "fail fast" should not be about code & feature quality but rather about determining proper scope, splitting features sensibly etc. But then we still have deadlines to meet and code quality suffers. What I'm saying that this kind of fast-moving environment actively discourages traditional (like doctors & civil engineers) engineering practices. You might have lots of (unit|integration|E2E) tests but the company may miss practices like proper security reviews and code won't be reviewed, tested and approved by multiple people like, say, bridge building plans are. This problem mostly comes up not with your usual web app but when critical systems are affected (like in the aerospace industry or industrial systems). But through supply chain attacks, nearly any system can be vulnerable these days. We should definitely have better regulation on how software is made.

wongarsu 5y ago
The problem with the waterfall model is that it only works if you can determine the requirements up front and they stay fairly static. Sometimes that's true, but all too often its impossible. But iterative development and fail-fast are independent of quality. If a company skips security reviews and is fine with technical debt because "it works, just ship it", what makes you think they would do security reviews or care about better-than-minimum code quality when following a waterfall system

runawaybottle 5y ago

Bad code is happening for non-malicious reasons. I’ll suggest these two being the main factors, and I’ll concede that it is conjecture, but I’m drawn to these two since I assume good-faith amongst all actors: 1) Everyone needs to pump out all of their bad code before they get to their decent code. Imagine your lifetime array of code, it will look like this [bad, bad, ...(lots of bad), bad, good, bad, good, good, ...(lots of good), good]. As you can see, you’ll have to pop (poop) all the bad out before you get to good. Some people have a smaller length array due to other factors (talent), but even so, there is bad in front of the array. What are the implications of this? That should be obvious. This industry hires people straight out of college or people in their mid 20s to be project leads. You do the math. 2) Lack of suffering. Many people haven’t had to toil in someone else’s codebase. Many people are given green-field projects that are scrapped quickly, at which point the business (or another business) gives a brand new project. Constantly building shit from scratch by yourself means you don’t understand pain. Go work in someone else’s garbage app to feel pain. Then you will rethink what good code is. Good code is not painful, and the definition of ‘not painful’ will be obvious to the survivors of pain. Solution: Continue to crap out your bad code in non impactful areas of the codebase and avoid crapping in critical parts. You have to crap somewhere, and that is understandable. Lastly, don’t turn down the experience of working in someone else’s labyrinth. The experience is valuable.