It doesn't really matter to me...
(as long as tabs stops/indent are 4)
Are software engineering “best practices” just developer preferences?
321–330 of 369 posts
Re: Are software engineering “best practices” just developer preferences?
#322Eh, 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…
> He then explained that he was working on an embedded control system for cars and all the variables in that system were global. Everyone should write Embedded at least once. It's a completely different world.
and hard real-time.
It really inverts some priorities (I mean development priorities, not the priority inversion on mars pathfinder)
Re: Are software engineering “best practices” just developer preferences?
#323Earlier quoted context omitted.
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.
Yeah, exactly. I got my degrees in electrical and computer engineering but mostly work as a software engineer. I got the PE just in case. The tests and other requirements are not exactly onerous; it's about what you'd expect for a worthwhile professional designation like becoming a CPA, an attorney, or even a CFA.
Not to toot my own horn, but I cruised through the FE and PE exams, but those exams filter out lots of people. Do you really want engineers who are incapable of performing simple calculations? The exams represent a minimum level of competence, and they shouldn't be difficult if you stayed awake in college.
Re: Are software engineering “best practices” just developer preferences?
#324If the entire Object Oriented and design patterns and Martin Fowler fan boys could read, they would be very angry.
Re: Are software engineering “best practices” just developer preferences?
#325Eh, 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…
Sometimes "best practice" is not because we need to worship a standard, but we need to have a standard. If everyone does everything in a different manner, you wind up with a tower of babel and support becomes impossible. I'm of the mindset where an organization needs to agree to specific principles that everyone adheres. Not dogmatically but pragmatically. Having that shared "best practice" makes is easier to support…
> I'm of the mindset where an organization needs to agree to specific principles that everyone adheres.
Agreed. But GP was talking about context dependency of those best practices. E.g. what might be a good best practice for a large organization inside a FAANG might be very bad for others. Some organization have very immediate feedback cycles. A significant problem in Amazon's online shop will probably show up immediately in sales numbers. A significant problem in the control software of a plane, might kill a few hundred people in a few years before people realize there is a problem. Therefore you cannot a/b test which auto pilot works better in a certain situation. (Although Tesla might disagree about that /s).
The point is every so called "best practice" should state under which precondition it is supposed to be applied. And most blog articles and books ignore that completely.
Re: Are software engineering “best practices” just developer preferences?
#326The biggest issue I saw with "best practices" in my career is the failure to take into account who it claiming it to be a best practice, and in what context . I saw too many junior developers read a rando blog article, then get a non-technical / semi-technical manager excited about something that made their life easier, even though it was by no means a good practice for the context at hand. Or alternatively, believe…
To add on to this, the current most preached about "best practices" comes largely from a de-risking, never-ever fail point of view, ie. 'safety'. Unfortunately with such standards also comes a concept known as 'acccountability', ie. 'ass-covering' practices that provide little practical value. This results in programmers no longer being able to iterate fast and having to rely on some third-party whose tradeoffs they…
I am not sure if I read you right here (correct me if I am wrong), but do you say that safety and stability concerns lead to bloated software because devs cannot blindly trust third party dependecies?
Because if so, yeah. You are responsible for the software you write and the dependecies you use. Software engineering is one of the least responsible engineering diciplines anyways. I am e.g. also a certified electrical engineer and of course I am responsible if my wrong decisions kill someone. If I would use a cheap chinese knockoff circuit breaker (because we can iterate faster if the stuff isn't expensive and certified) and someone gets killed, I go to jail. If someone gets killed and I can proof that I followed the currently agreed on state of technology my ass is covered. Of course you can get a lightbulb to light up without following any rule (and maybe this would be more efficient), but in EE the existing rules came as a consequence of deaths and rhe prevention of those is worth it.
In software engineering the worst that can usually happen (unless you work in IOT or industrial applications) is that you loose your user data. Many software devs don't care about whether they loose their users data and there are no tangible consequences. "Oh it was a software error" is still a good excuse, as if there was nothing which could have prevented that software error. I program software myself but I am al for stricter consequences in our profession because it would straighten out some heads who think this is all just fun and games for their personal joy.
Re: Are software engineering “best practices” just developer preferences?
#327> I was working on a Spring Boot REST API a few months ago and the senior engineer had defined every single service class as an interface and then implemented that interface in an actual @Service. The interfaces weren’t extended by multiple classes, this wasn’t an external library or a dependant, and there were no plans to implement additional classes later. Reason I avoid working in Java and especially the "senior j…
It doesn't make much sense for people who always heard and thought that "an interface just lists the public methods and properties of a class". In that view the classes always come first and the interfaces are unnecessary boilerplate.
However if instead you assume that "a class is just an implementation of an interface", then everything changes. Now the interfaces come first and classes are required to materialize them. In that paradigm objects only communicate with interfaces, never (or almost never) with other classes unless a specific implementation is required. Which is why an interface is always defined for a class even if there is no plan for other implementations of it.
Rather than a "contract", think of an interface as the description of a job. If you ever need to write a safety procedure, does it make more sense to write "In case of fire, call John; John happens to know how to extinguish a fire." or "In case of fire, call a fireman."? "Fireman" is an interface. "John" is a class implementing that job. It might be the only class in the codebase that implements it, but that is no concern of the caller. They just want that fire dealt with.
Re: Are software engineering “best practices” just developer preferences?
#328Eh, 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…
It is best practise to use RCCBs, because it turned out faulty wiring can kill people. But in Server rooms where you might not want to switch off the whole rack without warning when one device is faulty, you can use a device to monitor the residual current (RCM). Which issues a warning first, and only switches of when the residual current raises over the acceptable level. Different scenario, different best practise. (This is also the reason medical equipment is expensive).
I think a professional should be aware why a best practise exists and how to deal with a situation where for some reason it cannot be applied as you showed with the embedded example.
Don't forget however that many devs are against best practises out of lazyness or because they don't understand the reasons why they are best pracises.
Re: Are software engineering “best practices” just developer preferences?
#329Earlier 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…
C# properties are good until you need them to be delegates, and then they are annoying.
Re: Are software engineering “best practices” just developer preferences?
#330> 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 a…
> That's the 'D' in SOLID -- dependency inversion. An object's dependencies should be defined in terms of abstract interfaces, not concrete classes
DI does not talk about the interface keyword in Java. It talks about interface as the public surface of an object or system.
Programming to a Java interface declaration does not guarantee the code is depending on higher-level abstractions - this depends on how the interface is defined. An interface which just replicate the public surface of a class (a "header interface") is on the exact same abstraction level as the class, it just introduce needless boilerplate.