Live data from Hacker News

Are software engineering “best practices” just developer preferences?

floverfelt.org

181–190 of 369 posts

Re: Are software engineering “best practices” just developer preferences?

#181

"The parallel he drew was to another friend who’s a Civil Engineer. His friend had to be state certified and build everything to certain codes that stand up to specific stressors and inspections. I gave him the usual answer about how Software Engineers deal with low stakes and high iterability compared to Civil Engineers, but, honestly, he has a point." I've argued for awhile now that Software Engineering with a big…

In a way there are standards for software but those standards are not expressed in software terms. Firstly, most software is harmless. If it goes wrong people may be annoyed, but no one is harmed. But if I write software to control an aircraft, then it would have to abide by aviation standards. If I write financial software then I would have financial regulations to follow. Same for medical devices. So, there are sta…

Critical systems: https://en.wikipedia.org/wiki/Critical_system :

> There are four types of critical systems: safety critical, mission critical, business critical and security critical.

Safety-critical systems > "Software engineering for safety-critical systems" https://en.wikipedia.org/wiki/Safety-critical_system#Softwar... :

> By setting a standard for which a system is required to be developed under, it forces the designers to stick to the requirements. The avionics industry has succeeded in producing standard methods for producing life-critical avionics software. Similar standards exist for industry, in general, (IEC 61508) and automotive (ISO 26262), medical (IEC 62304) and nuclear (IEC 61513) industries specifically. The standard approach is to carefully code, inspect, document, test, verify and analyze the system. Another approach is to certify a production system, a compiler, and then generate the system's code from specifications. Another approach uses formal methods to generate proofs that the code meets requirements.[11] All of these approaches improve the software quality in safety-critical systems by testing or eliminating manual steps in the development process, because people make mistakes, and these mistakes are the most common cause of potential life-threatening errors.

awesome-safety-critical lists very many resources for safety critical systems: https://awesome-safety-critical.readthedocs.io/en/latest/

There are many ['Engineering'] certification programs for software and other STEM fields. One test to qualify applicants does not qualify as a sufficient set of controls for safety critical systems that must be resilient, fault-tolerant, and redundant.

A real Engineer knows that there are insufficient process controls from review of very little documentation; it's just process wisdom from experience. An engineer starts with this premise: "There are insufficient controls to do this safely" because [test scenario parameter set n] would result in the system state - the output of probably actually a complex nonlinear dynamic system - being unacceptable: outside of acceptable parameters for safe operation.

Are there [formal] Engineering methods that should be requisite to "Computer Science" degrees? What about "Applied Secure Coding Practices in [Language]"? Is that sufficient to teach theory and formal methods?

From "How We Proved the Eth2 Deposit Contract Is Free of Runtime Errors" https://news.ycombinator.com/item?id=28513922 :

>> From "Discover and Prevent Linux Kernel Zero-Day Exploit Using Formal Verification" https://news.ycombinator.com/item?id=27442273 :

>> [Coq, VST, CompCert]

>> Formal methods: https://en.wikipedia.org/wiki/Formal_methods

>> Formal specification: https://en.wikipedia.org/wiki/Formal_specification

>> Implementation of formal specification: https://en.wikipedia.org/wiki/Anti-pattern#Software_engineer...

>> Formal verification: https://en.wikipedia.org/wiki/Formal_verification

>> From "Why Don't People Use Formal Methods?" https://news.ycombinator.com/item?id=18965964 :

>>> Which universities teach formal methods?

>>> - q=formal+verification https://www.class-central.com/search?q=formal+verification

>>> - q=formal+methods https://www.class-central.com/search?q=formal+methods

>>> Is formal verification a required course or curriculum competency for any Computer Science or Software Engineering / Computer Engineering degree programs? https://news.ycombinator.com/item?id=28513922

From "Ask HN: Is it worth it to learn C in 2020?" https://news.ycombinator.com/item?id=21878372 :

> There are a number of coding guidelines e.g. for safety-critical systems where bounded running time and resource consumption are essential. These coding guidelines and standards are basically only available for C, C++, and Ada.

awesome-safety-critical > Software safety standards: https://awesome-safety-critical.readthedocs.io/en/latest/#so...

awesome-safety-critical > Coding Guidelines: https://awesome-safety-critical.readthedocs.io/en/latest/#co...

Re: Are software engineering “best practices” just developer preferences?

#182

Earlier quoted context omitted.

Well, the failure of a satellite would definitely result in harm to property and economic interests, so it sounds like you would still be an engineer in that case.

Dropping customer's database would indeed cause a lot of harm

Agreed. Seems like the definition might actually be wide enough to count the vast majority of software developers as engineers.

Re: Are software engineering “best practices” just developer preferences?

#183
Software engineering best practices are stuff like version control and automated tests. Many teams still don't have those and they ought to have them. "Squashing commits" isn't an example of best practice even if some people try to say that.

Re: Are software engineering “best practices” just developer preferences?

#184

Earlier quoted context omitted.

Math. Which seems that many practitioners are proud of not knowing

Logic maybe but a very large amount of software written does not use much if any math beyond the very basics.

Lots of people in other engineering disciplines don't use math beyond the very basics either. A large amount of parts are designed in CAE software which handles most/all of the mathematics. And in some larger companies, the person designing the part and the person testing the part are on different teams.

Re: Are software engineering “best practices” just developer preferences?

#185

Earlier quoted context omitted.

Doesn't that kind of imply that everyone's opinions are equally valid? If 95% of your profession is on the same page with a certain practice then I'd argue it's really not reasonable to go against the grain without a very good reason. I think "best practices" strikes a good balance between things that are personal preferences and things that are laws.

I'm not sure if there's anything 95% of developers are on the same page about. From what I've seen, every company has a different idea of what _best practices_ are. Generally comes down to what some influential developer likes.

From what I've seen, every company has a different idea of what _best practices_ are.

And that's fine. "Best practices" don't necessarily need to be universal in scope. Read the Knowledge Management literature and you'll see plenty of discussion of the idea of scoping "best practices" to in terms of "site best practice", "company best practice", "industry best practice" and so on.

There's also a lot of discussion about using different language other than "best practice" exactly to acknowledge that "best practices" aren't always BEST practices, if you get what I mean. Calling them something like "recommended practices" or "proven practices" or similar lingo gives a way to denote things that are recommended at least locally, without having to claim that they are either universal in scope, or absolutely "best" in any sense.

Re: Are software engineering “best practices” just developer preferences?

#186
post #112

Earlier quoted context omitted.

Some of us call ourselves "engineers". It just depends whether you want to pay the order for the privilege of having the title (and pretty much no other tangible benefit in 90+% of cases) :).

Genuine question. What is so important about the word "engineer" that people not licensed to practice it want to call themselves engineer? In Canada, I studied in a mechanical engineering technology program that lead to an engineering degree if you stayed on for 4 years. It was hammered into us that we weren't engineers until after you graduated and went through the professional licensing process. In Canada there is…

> So why is there so much resistance?

Because,

1) a PE license is useless for software/computer engineering.

2) the FE exam covers a bunch of irrelevant material.

3) once you pass the FE exam, there's no real mechanism to advance because there are no apprenticeships available in computer engineering. And you can't take the PE exam without the apprenticeship.

My college spent a lot of money getting an ABET accreditation for their CS/CE programs. As such, they pushed students really, really, really hard to take the FE exam. I went down the path to getting it and realized those aforementioned points. The study guide covered electronics theory that I had no idea about. It also covered silicon chemistry, which was only briefly covered at very high levels.

So I'd be learning pretty complex topics on my own, which have no professional value. Then, if I wanted to take the PE exam, I'd have to find a job where I could apprentice for four years. And, as we know, sticking with a job that long is terrible for your lifetime earnings.

So yeah, PEs are never going to be a thing in software unless they fundamentally change how engineers are licensed. Maybe if it was like nursing or law school where there's a big exam afterwards that you can take, and if you pass, you're licensed. But as it stands now, four years of apprenticeship after 4-5 years of schooling is ridiculous.

Re: Are software engineering “best practices” just developer preferences?

#187
post #110

Eh, kinda. Calling something a "best practice" is basically an appeal to authority. It means, "this is the right way to do things, for reasons I don't have time to explain." There are times when that's appropriate. But really, "best" and "right" are highly situational. Any rule of thumb, even the most basic and uncontroversial, has a situation where it doesn't apply. I was part of a discussion on a mailing list years…

Identifying a best practice is actually not as hard as people realize imo (although it may take some time), and only becomes hard when you let emotion and sources of emotion come into what should be a rational decision making process (such as preference for a certain tooling for reasons like familiarity or popularity in the field today rather than outright advantages vs other tooling).

To identify the best practice for anything, you start by doing a review of all the available practices in the field for a given problem you are working on. Then once you've reviewed the literature you can work out the pros, cons, caveats of each of these tools, and how these considerations affect your particular use case and your expected results. Then after doing that, the best practice out of available options will be readily apparent, or at the very least strongly justified, not by an appeal to authority or popularity or familiarity, but by looking at what the underlying technology actually does and how its relevant or not to your particular task at hand. In the end you will find the very best hammer available out of all the hammers people have made in this field for your particular unique nail.

Re: Are software engineering “best practices” just developer preferences?

#188

> Java is infamous for its verbosity. [...] This paragraph highlights something I've been saying for ages. Most criticism of Java needs to be directed towards Java programmers and not the language itself. The language allows you to simply make a class. You're not required to make an interface and then make a class that implements it, and yet, Java programmers do it anyways and then criticize the language for being ve…

> Getters and Setters? You probably don't need them. Classes can have public member variables.

We do need them if the objects interact with a lot the libraries that we use. Libraries that we didn’t make. They expect get/set.

I agree that getters/setters are very overrated. I tend to make public-final fields when I can. Most of the time I can’t though.

Re: Are software engineering “best practices” just developer preferences?

#189
post #162

Earlier quoted context omitted.

> Getters and Setters? You probably don't need them. Classes can have public member variables. The getter / setter debate and public fields is about exposing the internal implementation of the object (and thus making it unchangeable without breaking other code) and being able to reason about where the internals are used (if you do need to change them). For example, if I've got a java.util.Date exposed as a public fie…

Getters and Setters also permit you to specify that something can only be retrieved or assigned, but not the other. This is non-trivial in most programming languages so having this as a common pattern is useful. Though I like C#'s properties versus seeing a bunch of getFoo and setFoo methods running around, if Java had provided the same or a similar capability there would probably be no controversy. It's the noisines…

> Getters and Setters also permit you to specify that something can only be retrieved or assigned, but not the other.

Only retrieved? `final` and set the fields through the constructor.

Sure someone could implement setters-only if they wanted that. Except I’ve never seen it and get/set are always used instead. Just one layer of indirection for no benefit.

Re: Are software engineering “best practices” just developer preferences?

#190

> Java is infamous for its verbosity. [...] This paragraph highlights something I've been saying for ages. Most criticism of Java needs to be directed towards Java programmers and not the language itself. The language allows you to simply make a class. You're not required to make an interface and then make a class that implements it, and yet, Java programmers do it anyways and then criticize the language for being ve…

[deleted]
Post reply on HN