Are civil engineering "best practices" just legal preferences?
It’s called “building code”.
Are software engineering “best practices” just developer preferences?
21–30 of 369 posts
Re: Are software engineering “best practices” just developer preferences?
#22Having an interface for a single implementation is just redundant. A class already has an interface - it's public API. Other than that I agree, most "best practices" are subjective and boil down to personal preference.
> Having an interface for a single implementation is just redundant. A class already has an interface - it's public API.
Depends on the language.
And sometimes you want to enforce a public contract of any implementation (current and future).
Personally for me, the biggest gain I see when writing against interfaces is that any class which expects a interface is already prepared for test-doubles, as opposed to classes written against concrete implementations which may even be initialised internally. Then just even starting to write a test becomes a so much bigger task.
Of course, everything with moderation, sometimes even moderation itself ;)
Re: Are software engineering “best practices” just developer preferences?
#23The issue here is that people abuse the term and call many things and anything a "best practice".
An actual best practice is based on objective criteria and experience, and can be shown to lead to better outcomes over the alternatives.
If that's not the case, then it is just a preference, indeed.
For instance, version control is a best practice. It objectively improves software development. So is unit testing, etc.
Re: Are software engineering “best practices” just developer preferences?
#24Software engineering seems partially creative partially technical - so on the creative parts, yes absolutely teams should self define their preferences. Scrum vs agile vs whatever else IMO should be a team/org preference. However like someone else said some engineering has to be liable for criminal prosecution in some cases. So you need some practices to be enforced.
Re: Are software engineering “best practices” just developer preferences?
#25Best practices create a shared experience that can help get you out of trouble when that practice was a bad decision.
Re: Are software engineering “best practices” just developer preferences?
#26Earlier 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.
It’s almost like we have different standards for different types of engineering.
The devs writing code for the next social media app operate under very different standards than the ones writing code for nuclear reactors. And that’s ok.
Re: Are software engineering “best practices” just developer preferences?
#27> How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is?
So the world had no engineers before the creation of governing bodies? That doesn't sound right to me. Thus, I think this person's definition needs some tweaking.
Re: Are software engineering “best practices” just developer preferences?
#28Steven 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…
Eh, I mean we've been building computer chips for approximately the same amount of time as computer software, and it's pretty clear chip engineering is more like civil engineering than software engineering. I would guess many of the best practices in bridge building in the modern day were developed in the last 70 years.
I think it's that engineers of physical things have many more hard constraints they have to wrestle with, and software engineers largely don't. Your code doesn't need to obey the rules of gravity and chemistry and materials science, it just needs to somehow accomplish the task.
And you see those best practices in the places of software engineering where there are hard constraints: cryptography. high performance code. realtime systems.
It's not just a senior engineer's opinion whether you should use ruby or C if you're writing the firmware for your race car. If you use md5 to hash user passwords on a major site, you'll be hung from the rafters.
Re: Are software engineering “best practices” just developer preferences?
#29Earlier 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.
Which was left in the hands of a small elite from the beginning. I don't think reddit could have been born that way :)
Re: Are software engineering “best practices” just developer preferences?
#30Earlier quoted context omitted.
Oh yeah the last bridge collapsed, but that is a known issue. It is fixed in this bridge, trust me.
Blame the contractor is what you normally do in this case :-) I once built a system reverse engineering a program used for soil analysis to see why one of our bridges fell off its suports.
Can you tell us more? This sounds oddly fascinating.