5 ms·
To add on to this, the current most preached about "best practices" comes largely from a de-risking, never-ever fail point of view, ie. 'safety'. Unfortunately
by oreally 5y ago
To add on to this, the current most preached about "best practices" comes largely from a de-risking, never-ever fail point of view, ie. 'safety'. Unfortunately with such standards also comes a concept known as 'acccountability', ie. 'ass-covering' practices that provide little practical value.
This results in programmers no longer being able to iterate fast and having to rely on some third-party whose tradeoffs they don't understand, resulting in slow, bloated software and dissatisfied programmers.
- atoav 5y agoI am not sure if I read you right here (correct me if I am wrong), but do you say that safety and stability concerns lead to bloated software because devs cannot blindly trust third party dependecies? Because if so, yeah. You are responsible for the software you write and the dependecies you use. Software engineering is one of the least responsible engineering diciplines anyways. I am e.g. also a certified electrical engineer and of course I am responsible if my wrong decisions kill someone. If I would use a cheap chinese knockoff circuit breaker (because we can iterate faster if the stuff isn't expensive and certified) and someone gets killed, I go to jail. If someone gets killed and I can proof that I followed the currently agreed on state of technology my ass is covered. Of course you can get a lightbulb to light up without following any rule (and maybe this would be more efficient), but in EE the existing rules came as a consequence of deaths and rhe prevention of those is worth it. In software engineering the worst that can usually happen (unless you work in IOT or industrial applications) is that you loose your user data. Many software devs don't care about whether they loose their users data and there are no tangible consequences. "Oh it was a software error" is still a good excuse, as if there was nothing which could have prevented that software error. I program software myself but I am al for stricter consequences in our profession because it would straighten out some heads who think this is all just fun and games for their personal joy.
- BeFlatXIII 5y agoIMO, much of the low engineering standards in software is from a (potentially false) awareness in the industry that most products we work on simply aren't that valuable. If a bug deletes my Twitter account, that sucks to me be for a day but no real harm was done. The people who work in banking or healthcare IT tend to know better and have correspondingly higher (though still shockingly low) standards.
- diroussel 5y agoHaha. The banks ought to know better, but in fact due to software being hard to prove correct, we still get major disasters like the TSB migration failure. It caused real world problems like peoples house purchase deals falling through and money getting lost: https://www.theguardian.com/business/2018/jun/06/timeline-of-trouble-how-the-tsb-it-meltdown-unfolded https://www.theguardian.com/business/2018/jun/06/timeline-of... The thing, is there is seemingly no appetite to try to prove correctness of even single machines systems. Let alone distributed systems. I wonder if ever there will be a time where this kind of proof is cheap enough to be acceptable to business.
- Zababa 5y agoDo you have any concrete examples of that? I think I kind of see what you mean, and I have a feeling that this is mostly right, but I'm not sure.