71–80 of 369 posts
Civil engineering best practices are written in blood, but I think software engineering best practices can be stretched to include sweat and tears too.
Earlier quoted context omitted.
Pretty much. IT as a field is a toddler. But it makes so many people happy we don't care it's still at the anal stage. Maybe in a century techs and standards will stabilize.
>Pretty much. IT as a field is a toddler. It's exactly as old as nuclear engineering. If it's a toddler, it's because of the mentality of the people involved, not because there was no time to figure things out.
Not to mention funding for governments that actively sell exploits to other nations. Standards seem to be left up to the industry. I saw the Kubernetes hardening guildelines from NIST a while back that was cool.
Are civil engineering "best practices" just legal preferences?
A Practical Guide for Policy Analysis by Eugene Bardach. ( https://us.sagepub.com/en-us/nam/a-practical-guide-for-polic... ) and https://en.wikipedia.org/wiki/Eightfold_path_(policy_analysi...
Legal practices often follow from established best practices rather than the other way around.
There are many practices that solve a problem. Some of them have an intrinsic "better" to them. Of those, when trying to solve a problem you look at all of them. The one that fits your needs best is then the best practice.
> Don't be mislead by the word best in so-called best practices research. Rarely will you have any confidence that some helpful-looking practice is actually the best among all those that address the same problem or opportunity. The extensive and careful research needed to document a claim of best will almost never have been done. Usually, you will be looking for what, more modestly, might be called "good practices."
Steven Sinofsky gave a talk and said something to the effect of, we've been building roads, bridges and edifices for thousands of years. So, best practices and solved problems abound---and even then we still get it wrong sometimes. Whereas, software engineering is maybe 70 years old (generously)? So, there is much to learn and a lot of "baseline" knowledge that has yet to be established. I think it's a good way to th…
Civil (and other engineering) got better because there was motivation to improve that came from multiple directions: literal lives at stake, the pride of good craftsmanship, iterative or even grand steps forward in knowledge, etc. Software engineering as a discipline is dominated by appeals to authority ("Clean Code", "Google does it this way", "Djikstra said so", etc.) without any (or at least not much) attempt to a…
I would expect a software engineer to be working on safety-critical systems. Power grid control, military applications, etc. And I hope there's a massive amount more rigor applied to their work than there is to mine.
All the problems stated require more context: - extract an interface or not -> an interface can speed up compilation (under the right conditions) - pass more or less arguments -> how many call sites exist? What’s the performance difference? Would it complicate testing? - testing -> depends on what you’re building, when do you need it by, and how problematic a bug may be (and more) The reason it looks like some random…
More or less right about hard rules. They're not truly hard, and it's different in different countries. Some countries have performance based rules, others have descriptive rules (must have 35mm of concrete cover over reinforcement bars) but even in those situations you can usually get some sort of person to overrule the rule, it's just costly in both time and money, but sometimes its worth it.
Take ultra high performance concrete for example. It's almost a different material compared to the normal stuff. But for run of the mill construction everyone kinda likes sticking to the rules because it's like outsourcing handling all the edge-cases. Kinda like using Postgres over writing your own persistence layer.
As for hard rules in software, that would be tough. It's much more multidimensional and maneuverable than civil engineering is and we have less history dealing with it. Also, there are way more security concerns than civil engineering, which is mostly about safety concerns, where there are no arms races against you.
We could still do it abstractly though. Favouring maxims and penalties over nitty gritty rules.
I have to fight the urge to ask for citations whenever I see someone pull out one of these chestnuts. Rather than be contentious, I just think about whether or not their argument needs the extra oomph of authority that they're trying to give it. My hope is that not rewarding disingenuity reduces its power.
Best practices (generally opinions based on reasoning): language choice, KISS/DRY/YAGNI, linter rules, unit tests, static vs dynamic linking.
Standards (de-facto, at least): ISO, RFCs, PCI, and whatever is relevant for the industry the solution is for.
> How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is? We call ourselves software developers in Canada. According to Canadian engineering[1]: The "practice of engineering" means any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising, or managing any of the foregoing, that…
I can't imagine someone arguing that avoiding tight coupling is a personal preference.
I currently work on a project that has about 1M SLoC in Java. Approximately 95% of the classes that have the @Service annotation are tightly coupled at the time of writing this. Yet, there are no issues with this approach.
Why? Because loose coupling is a nuisance if introduced at the expense of more code, which is how interfaces are currently done in Java, as opposed to them being implicit, based on implemented methods within a class, like Go does it.
In about 5% of the cases, we need more than one implementation and introduce an interface. In all the others, we don't. Now, what would happen if every single service would have an interface in front of it? The codebase would become far larger and it'd become more cumbersome to alter it.
Furthermore, IDE refactoring tools make it a non-issue - just choose which methods you want in your interface and create one, doing so at the point where you are clear about which methods are implementation specific and which aren't. Most smart tools will even offer you to replace your concrete classes with interfaces where possible.