Are software engineering “best practices” just developer preferences? • Hacker News Board

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

#161

Post by habitue » Thu, Sep 30, 2021, 4:28 PM UTC

Drew_ wrote: post #158

habitue wrote: post #28

Earlier quoted context omitted.

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 wrestl…

> 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. Is it actually anything like civil engineering? To my knowledge chip engineering revolves around yield. There's no such analogous concept in designing buildings that can only be reasonably constructed correctly…

Sure, and civil engineering is really different from chemical engineering. But those are minor compared with the differences between physical engineering disciplines and software engineering.

Software engineers:

- cost of components is $0 (use one class or split into 2, there is no cost metric to decide)

- physics don't apply to components (we can't use this doping agent because X or Y. We need to move the factory to an area of low seismic activity to improve yields etc.. etc..)

Basically, physical engineers have so many constraints, solving the problem is the hard part. Software engineers have so few constraints, usually solving the problem is the easy part, and we have time left over to argue about abstract cleanliness concepts like composition vs. inheritance and such.

(Again, this is the rule, the exception is problems like "We need this service to do 2 million requests per second", and there we don't argue about functional vs. OOP, you do anything you can to hit the number)

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

#162

Post by shagie » Thu, Sep 30, 2021, 4:32 PM UTC

Sohcahtoa82 wrote: post #140

> 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.

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 field and someone uses it, I can't change that later to a java.time.LocalDateTime unless I change all of the things using it. If this is a library that others are using it may mean a cascade of unknown changes.

If, on the other hand, the Date was exposed as a public Date getDate() { return date.clone(); } then I don't have to worry about it. When the internals are changed to LocalDateTime, then Date getDate() { return Date.from(local.atZone(ZoneId.systemDefault()).toInstant()); } and everything will still work.

I don't have an issue with the infrequently used "default package private" level of field visibility where only classes in the same package can see that field as that limits the range of the changes to the classes within single package (in a single project).

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

#163

Post by 8note » Thu, Sep 30, 2021, 4:37 PM UTC

skipants wrote: post #120

dmalik wrote: post #60

> 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…

And yet, in Canada, every Software Engineer I know works no differently than a Software Developer.

They can sign and stamp things though, which is a difference on the work your company can do

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

#164

Post by habitue » Thu, Sep 30, 2021, 4:40 PM UTC

dtech wrote: post #74

sidlls wrote: post #34

Earlier quoted context omitted.

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…

This is a symptom of the lack of knowledge not a cause. Imagine you want to built a building but no one really knows how, then copying successfully completed buildings, and established construction engineers and companies is a pretty good idea. That's what's going on in SE.

The difference is the feedback is pretty incontrovertible if you build a building and it falls down. If you use composition instead of inheritance, the evidence of whether you're right or wrong comes in the form of ... slightly faster refactoring two years later? Maybe?

All of the stuff engineers argue about and that seem really subjective are the things where you just get very little feedback about who is right or wrong.

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

#165

Post by 8note » Thu, Sep 30, 2021, 4:44 PM UTC

Drew_ wrote: post #158

habitue wrote: post #28

Earlier quoted context omitted.

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 wrestl…

> 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. Is it actually anything like civil engineering? To my knowledge chip engineering revolves around yield. There's no such analogous concept in designing buildings that can only be reasonably constructed correctly…

Buildings are constructed correctly closer to 10% of the time, I assume. The ones built incorrectly still get used, just with lower lifespans and are more likely to run into issues.

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

#166

Post by Jtsummers » Thu, Sep 30, 2021, 4:48 PM UTC

shagie wrote: post #162

Sohcahtoa82 wrote: post #140

> 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. 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 noisiness of the Java solution that seems to irk people more than the concept.

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

#167

Post by TuringTest » Thu, Sep 30, 2021, 4:51 PM UTC

Drew_ wrote: post #160

TuringTest wrote: post #145

Earlier quoted context omitted.

As an oficially qualified computer scientist, I can say that software is grounded in mathematics, but this does not imply what you're thinking. *All* formalisms, including mathematics, are in the end nothing but an incredibly precise language to talk about ideas in your head. Programming languages are created for communication, so this is specially true for them. The fact that code has an extremely precise semantics…

> Formal proof is a convenient way to check that your detailed, precise assertions are consistent with your initial axioms. This doesn't prove at all hat there are no errors in your code, only that there are no contradictions in what you are saying. Your specification could still be wrong, and then you could still be saying the wrong thing in terms of what you intend to say or achieve; and the formalism won't help. S…

Great example!

How does research in software assurance treats the human side of behaviors and desires, which can't be formalized? Are there protocols that can increase reliability for an established purpose?

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

#168

Post by Drew_ » Thu, Sep 30, 2021, 4:52 PM UTC

habitue wrote: post #161

Drew_ wrote: post #158

Earlier quoted context omitted.

> 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. Is it actually anything like civil engineering? To my knowledge chip engineering revolves around yield. There's no such analogous concept in designing buildings that can only be reasonably constructed correctly…

Sure, and civil engineering is really different from chemical engineering. But those are minor compared with the differences between physical engineering disciplines and software engineering. Software engineers: - cost of components is $0 (use one class or split into 2, there is no cost metric to decide) - physics don't apply to components (we can't use this doping agent because X or Y. We need to move the factory to…

Well I think this is just a case of easy Software Engineering vs hard Software Engineering where the requirements are hard to satisfy.

Most of the industry does easy Engineering and that's what we talk about for the most part. The part of the industry that does hard engineering (the largest orgs, developers of mission critical systems like weapons) keep mostly quiet about how they solve their problems because that's a trade secret or highly classified.

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

#169

Post by agentultra » Thu, Sep 30, 2021, 5:01 PM UTC

auxym wrote: post #92

agentultra wrote: post #79

Earlier quoted context omitted.

It'll be interesting to see if they can ever manage to enforce it. I haven't heard of any cases yet since Microsoft challenged them and won.

Microsoft lost their appeal in Quebec https://www.oiq.qc.ca/en/media/pressReleases/Pages/default.a...

That's interesting, thanks for sharing!

INAL; it seems, to me, difficult to enforce. You're not allowed to call yourself an engineer but you can still practice as one as long as you call yourself a developer. What's the difference? In practice... very little.

Most developers I know do all the things professional engineers do.

Unless the government wants to step in and say that you're not allowed to release software without a professional software engineer at the helm I think it's trivial. Unless a company pays the insurance of an engineer and faces severe penalties for disregarding their direction I don't see the point of hiring a professional software engineer. Companies will simply hire developers rather than deal with trifling matters like liability.

And we'll continue to see avoidable security breaches in the wild for ever and onward because of it. The financial incentives are behind "move fast and break things," rather than "protect the public interest."

(Mind you I think we should have more of the latter and I'm all for liability for the things we create as long as we're in control of our future... I'll take the exam if I can be brought in with my 20+ years of experience)

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

#170

Post by rajin444 » Thu, Sep 30, 2021, 5:04 PM UTC

dntrkv wrote: post #44

rajin444 wrote: post #5

Earlier quoted context omitted.

To make the comparison fair, in that world civil engineers would also have the ability to change the laws of physics.

Or you can just compare them to software engineers that work on critical software like launch systems and nuclear reactors. Software can be just as reliable when there is a need for it. Thing is, 99% of the time you don't need those extra 9s.

Yeah, that’s a very good point! I imagine if civil engineers could change physics, they’d lockdown what you’re allowed to change for critical systems. And like you said, systems that don’t need the 9s can experiment and learn.