Engineering is the wrong classification. I think the problem is it's new enough that people try to relate it to other disciplines. Coding is just its own thing.
Are software engineering “best practices” just developer preferences?
81–90 of 369 posts
Re: Are software engineering “best practices” just developer preferences?
#82Right, but have you ever worked in a place where no practices at all are being followed? Where there are hacks after hacks, giant classes with giant methods, no interfaces, static methods, bad names everywhere, you need to find a bug? good look, you want to write a test to avoid regression? Ok that would take you 5 times more time. I agree, following a “best practice” without understanding the “bad practice” that it’…
> I agree, following a “best practice” without understanding the “bad practice” that it’s trying to prevent is silly. But just discarding best practices because no one understands the reasons behind is also silly.
I would argue that there is also a lot of value in following team-level best practices even if you do not fully grasp the rationale or understanding "bad practices". For starters, it ensures that the team's work complies with the principle of least surprise and follows a common and standard style, which helps with onboarding and forming a mental model of where and how all things are.
Re: Are software engineering “best practices” just developer preferences?
#83Earlier quoted context omitted.
Furthermore, there are far fewer physical constraints in software, so the range of possible designs is dramatically wider. (Actually I dare say that sotware itself has no physical constraints at all: software artifacts and software executions do.)
Which is why I don't buy the "software has only been around for 70 years so give it time" argument. Software has nothing to be grounded in like other engineers do with physics. It's most likely always going to be endless cargo culting.
It's more like mathematics. While it's true that everyone can invent their own maths, this is only really done in advanced academia for research. Almost everything in practical use is standarized. No-one is arguing about whether you need integration or what the right notation for differential equations is.
This took time to achieve. You wouldn't be able to read Newton's papers easily, even though a large amount of high school mathematics is based on things he invented/discovered.
Re: Are software engineering “best practices” just developer preferences?
#84Steven 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…
Also, there isn't that much in the way of scientific grounding. Mechanical engineering has physics as a foundation. Chemical engineering has chemistry as a foundation. What is the scientific foundation of software engineering? I suspect it is a mix of cognitive science, linguistics, and anthropology.
An old HN post - https://news.ycombinator.com/item?id=20912718 and its corresponding material - https://cse.buffalo.edu/~rapaport/Papers/phics.pdf looks to address some of that.
Section 3 gets into the "what is computer science". 3.10 through 3.13 get into the engineering aspect. Section 6.5 puts it into historical context.
Re: Are software engineering “best practices” just developer preferences?
#85Developers end up at local maxima because a whole bunch of practices add up to a working system. It's a mistake to champion any single practice without understanding how it fits into an ecosystem: time budget, testing, language features available, efficiency, tolerance for errors, imposed deadlines, third-party technical ecosystem, etc. It's all about the system where they all work together.
To truly suggest something as a best practice, you need to understand what it requires from the technical and social environment around it, and when it applies and doesn't apply. We're nowhere near that level of discipline as a field. This lack of discipline is why we wince when we hear that a startup is implementing something like voting machines: we know the financial incentives that lead to startups focusing on speed, and we can imagine the discipline that voting systems require. We know there's a mismatch between the social environment and the likely project management approach. But we're blind to the social and technical requirements that allow other practices to work well. When is it appropriate to use inheritance? Someone will inevitably say, "You shouldn't use it?" Why does it work so well in Rails?
IMO it's how developers like John Carmack[0] and Martin Fowler[1] can make opposite arguments about things like the benefits of having code inline or in functions. These two opinions work in conjunction with their environments; maybe video game and aerospace coding requires budgeted performance requires mutability, so Carmack has to control how you interleave side-effects. Maybe enterprise-grade Java programming doesn't have much of a performance budget at all, or maybe he values isolating testable functions more, so Fowler can take other approaches that allow more "readable" styles and not worry so much about side effects (since there are few).
[0] http://number-none.com/blow/john_carmack_on_inlined_code.htm...
Re: Are software engineering “best practices” just developer preferences?
#86> the senior engineer had defined every single service class as an interface and then implemented that interface in an actual @Service. The logic from the senior engineer was that the interface represented the “contract” and the class the business logic. This is mentioned as bad thing, but having service interfaces really helped in a large Java project I worked, where we had to reimplement and extract some important…
There is a large difference between dogmatically declaring that every single service needs an interface, versus just introducing them at the point where you actually need more than one implementation.
I think that's the author's original argument - not that interfaces are bad in of themselves, but that cargo culting is problematic.
Furthermore, starting with an interface oftentimes makes you create the wrong abstraction, however when you have a concrete implementation, in my experience extracting an interface becomes easier to do, though mostly thanks to excellent IDE tooling.
Re: Are software engineering “best practices” just developer preferences?
#87Some certainly are, many are not.
To discern the two is very easy. You write a piece of code. If someone else or even yourself can still understand it after a month, then you're practicing the "best practices".
Whereas, if you don't follow some "best practices" and they're still clear to others, they are just "developer preferences".
Re: Are software engineering “best practices” just developer preferences?
#88There 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…
100% that's true! I'm not saying developers having preferences and everybody abiding by them is a bad thing, more just that a lot of what constitutes "best practices" are often preferences and we should call them that.
Re: Are software engineering “best practices” just developer preferences?
#89After reading this article, the theory that comes to mind is that "best practices" not just developer preferences - rather, "best practices" is cargo culting by mediocre programmers, trying to copy techniques that a really skilled programmer once employed to do amazing things.
This is the part of the article that made me think this:
>As I type this, I’m in a discussion about whether it’s better to pass a few unnecessary parameters to simplify a bash script’s internal logic or pass fewer parameters and make the bash script more complex.
This sounds like they're on the verge of parameterized, object-capability design - passing in the paths to operate on, rather than hardcoding some internal logic to determine what to do. If you do this in the right places and at the right time, you can do amazing stuff, reuse scripts in totally novel environments and for novel purposes. At other times, it's not necessary. But I'm guessing neither side really knows how to use that to do amazing stuff.
Some programmers don't have the skill to recognize when a specific technique is justified or unjustified. So, unmoored from technical reality, they just argue about cultural norms - blindly copy what someone else did once, which brought someone else success - cargo culting.
That all sounds very mean, but if this is what's actually going on, I'm not sure what the solution is. Maybe more focus on really impressive and amazing concrete projects, rather than just individual practices in isolation?
Re: Are software engineering “best practices” just developer preferences?
#90Best practices in civil engineering are connected to outcomes. You know that something is a good practice if not doing it causes things to collapse or catch on fire.
"Best practices" in software engineering are usually about internal development processes and don't have any verifiable connection to outcomes.
In other words, we have two entirely different things labeled with the same name. People who commonly use the phrase "best practices" for software are literally trying to confuse you and generally are not worth listening to.
That said, some things in software are worth analyzing to have a better process, but those things need to be examined within a specific context. If someone claims that you need to, say, create an interface for every class, they should be able to explain why and how it is relevant to your work. If people make claims they cannot explain by connecting them to meaningful outcomes, those people are, again, not worth listening to. They might be mindlessly parroting something they have heard without having any clue as to the meaning of the practice. Unfortunately, our field is full of "professionals" that do exactly that.
Software is a pretty messed up domain that is frequently a self-licking ice-cream cone. (You write code to solve problems created by other code.) Because of that, it's often socially mediated, just like non-engineering fields. To establish anything for real in this self-referential environment you need to be able to have conversations about costs, tradeoffs and outcomes - within a specific context.