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

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

#171

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

Jtsummers wrote: post #166

shagie wrote: 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…

Java now has records which handles the creation of getters (and since its an immutable, it doesn't have any setters).

https://blogs.oracle.com/javamagazine/post/records-come-to-j... and https://dzone.com/articles/what-are-java-records

I'm really looking forward to using the local records defined mid stream for bundling the information to the next part.

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

#172

Post by tester756 » Thu, Sep 30, 2021, 5:20 PM UTC

charles_f wrote: post #149

I hate the expression "best practice", it's so, so often used by someone to justify applying cargo cult without actually understanding why. "Hey why are you having a try-catch there, it seems like it's just gonna break our stack trace and we don't even graciously recover from it" - it's best practice "Hey why are you using model/view/controller folders?" - it's best practice "Why are you building microservices?" - be…

Same with Clean Code, SOLID, DD

SOLID is especially funny because majority of developers doesn't understand / can explain it, let alone have read papers e.g [0],

except maybe S letter, yet everybody acts like they do SOLID*.

Or Clean Code's small function craziness or misinterpretation and going into "avoid comments" approach

* - unless you ask for details

[0] - https://www.cs.cmu.edu/~wing/publications/LiskovWing94.pdf

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

#173

Post by Drew_ » Thu, Sep 30, 2021, 5:23 PM UTC

TuringTest wrote: post #167

Drew_ wrote: post #160

Earlier quoted context omitted.

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

Many times there are authorities that have formalized protocols for systems involving people. For example, the FAA has prescribed thresholds where pilots should be alerted of possible failures when navigation system measurements have exceeded those thresholds. Other times thresholds like those can be found just through user testing and feedback. The goal there is to ensure safety without losing the confidence of the user or overwhelming them with information.

There are a number of general Software Assurance protocols. I'm not super familiar with them, but DO-178C is one I hear about often which is a process specifically for assuring/certifying airborne systems.

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

#174

Post by tester756 » Thu, Sep 30, 2021, 5:25 PM UTC

jaywalk wrote: post #141

milkytron wrote: post #134

Earlier quoted context omitted.

That's because it is a strange definition. If you work on the software in a self driving system in a car, that makes you an engineer. If you're working on software for a space satellite with no occupants... that's not an engineer?

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

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

#175

Post by letwhile » Thu, Sep 30, 2021, 5:31 PM UTC

I don't see the point of this. As an engineer you get a task and then pick a solution from a bag you have, that is not optimal, but fulfills the constraints you got. Time and money, features, accuracy, speed, waste, etc.

Where is the difference with software? You get the same kind of constraints and need to build something from libraries and custom code, that fits all of them.

There may be more constraints for a skyscraper than a small garage, and there are more constraints for airplane software than a website. You can't write flight controllers in javascript, the same way you cannot build your airplane out of toilet paper. There are also more constraints for airplane software than for your backyard garage. It only depends on the regulations in the field. Most of the times software doesn't have the potential to harm people, like houses and bridges have. So you have less regulations.

If you want to build a bicycle, there is no right solution either. You could benchmark it by weight, like you could benchmark software by memory usage.

Most engineering products only rely on best practice and the way the company does it since years, from experience. There is no "right" solution, neither in civil-, nor in software-, nor in engineering in general.

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

#176

Post by bitwize » Thu, Sep 30, 2021, 5:36 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…

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

That's the 'D' in SOLID -- dependency inversion. An object's dependencies should be defined in terms of abstract interfaces, not concrete classes. The verbosity is just boilerplate, and it would appear in any statically typed language if you're following SOLID principles.

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

Getters and setters are part of the JavaBeans spec for being able to load and configure arbitrary beans. If you're writing JavaBeans, as many EJB or Spring application developers are, you'll use getters and setters.

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

#177

Post by thereddaikon » Thu, Sep 30, 2021, 5:39 PM UTC

sime2009 wrote: post #91

thereddaikon wrote: post #69

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

While that's true, those standards don't really fully account for the needs of proper software engineering practices IMO. You can say aircraft code follow aerospace standards yet those standards didn't stop Boeing from making a system that overrode pilot input while only relying on two sensors. It also didn't stop Boeing from launching a space capsule that didn't have the thrusters mapped properly. Nor did it prevent Lockheed from shipping GPS code that caused the navigation system of the F-22 from crashing when it crossed the international dateline. Standards and norms aren't the same thing as a building code. Civil Engineers have a code they must meet at minimum for the things they build. There are ways that certain things must be done and they have to sign off on every project. We don't see that with equally important software. For some reason if a bridge collapses and it was found that it was designed wrong the engineer goes to jail but if a plane crashes because its autopilot had design flaws the developer doesn't.

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

#178

Post by tannhaeuser » Thu, Sep 30, 2021, 5:42 PM UTC

hyperman1 wrote: post #35

There is value in predictability, even if it stems from someone else's preferences. Current home wiring requires you put wires in the wall at (I think) between 10 and 20 cm from the border, and a small number of cm inside the wall. This means you only have to check that zone, and can use detectors, to find the wires. My home is from the 1950's. Some wires go diagonally from top left to bottom right at the other side…

1950's onwards they used ribbon cables close to surfaces for household wiring. It was best practice, just not today's.

As a freelancer jumping projects, I can't help but see parallels, in that you've really got to study code bases wrt the time of authorship to understand their particular idiosyncrasies.

In the 2010's, people believed in "REST" without considering the context in which these concepts were introduced (eg thin browser UIs, or generalizations thereof as a baseline). Customers, even highly capable devs, flaunt their REST best practices, yet see HATEOAS as optional and pretentious, failing to see the entire point of loose coupling and discovery, and engaging in zealotry about squeezing parameters into URLs instead. Or pretend to, to stop pointless discussions with mediocre, bureaucratic peers.

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

#179

Post by wheelinsupial » Thu, Sep 30, 2021, 5:51 PM UTC

Drew_ wrote: post #150

wheelinsupial wrote: post #132

Earlier quoted context omitted.

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…

Because there's a pretty clear difference between software engineering and simply just writing code and people who do the former pride themselves on that work and want to be recognized for it as an engineer rather that just some programmer. You would much rather be recognized as the person who devises the plumbing system for a building rather than just being a "plumber".

There is a formal qualification process to be called an engineer. If they truly feel that they should be recognized, then they can go through the process.

Because they aren't going through the process the word and the recognition can't be that valuable.

I feel there is a contradiction in here somewhere that I can't reconcile.

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

#180

Post by wheelinsupial » Thu, Sep 30, 2021, 6:01 PM UTC

allo37 wrote: post #156

wheelinsupial wrote: post #132

Earlier quoted context omitted.

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…

Calling yourself an "engineer" involves licensing fees, continuing education, and the most fun of all - a university degree. Some jobs require you to be a member, but most of these jobs aren't in software. So most software people I know just use adjacent titles like "developer" or "designer". It's essentially the same job - just without all the extra responsibility. The word "engineer" has a certain social clout to i…

On the upper end (probably even in the middle) software developers earn more than licensed engineers. I'm pretty sure your mom can brag about her child the developer making 3x what her friend's child the engineer makes.

There are engineers who end up moving to software for just this reason.

Software is super important and becomes more so over time. I'm not sure why being proud of being a developer isn't enough and why it has to end up with wanting to use the term engineer.