Are software engineering “best practices” just developer preferences?

Eh, kinda. Calling something a &quot;best practice&quot; is basically an appeal to authority. It means, &quot;this is the right way to do things, for reasons I don&#x27;t have time to explain.&quot; There are times when that&#x27;s appropriate.<p>But really, &quot;best&quot; and &quot;right&quot; are highly situational. Any rule of thumb, even the most basic and uncontroversial, has a situation where it doesn&#x27;t apply. I was part of a discussion on a mailing list years ago, where somebody got flamed harshly when he mentioned using a global variable. He then explained that he was working on an embedded control system for cars and <i>all</i> the variables in that system were global. The team was well aware of the pitfalls of global state and used a combination of documentation, static analysis, custom tooling and elaborate testing to mitigate them. It was a considered design choice that made it possible to develop high-performance, hard-realtime software that could run on very limited hardware.

The biggest issue I saw with &quot;best practices&quot; in my career is the failure to take into account <i>who</i> it claiming it to be a best practice, and in <i>what context</i>. I saw too many junior developers read a rando blog article, then get a non-technical &#x2F; 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 some vendor carte blanche when they tell you their product somehow follows a best practice.<p>The overarching problem is that yes, there is software engineering going on in the world, but most organizations are not willing to do engineering. I don&#x27;t blame the technical staff - they often have good intentions - but rather the typical business is not willing to pay the cost in time or money to do long-lasting engineering practices. This is one of the things not enough of us think about in our career choices - am I going to a place that practices fire drills or engineering?

&gt; How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is?<p>We call ourselves software developers in Canada.<p>According to Canadian engineering[1]: The &quot;practice of engineering&quot; means any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising, or managing any of the foregoing, that requires the application of engineering principles, and that concerns the safeguarding of life, health, property, economic interests, the public welfare, or the environment.<p>To be considered a work of engineering, then, that a piece of software (or a software-intensive system) must meet two conditions:<p>1. The development of the software has required “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.”<p>2. There is a reasonable expectation that failure or inappropriate functioning of the system would result in harm to life, health, property, economic interests, the public welfare, or the environment<p>[1] - <a href="https:&#x2F;&#x2F;engineerscanada.ca&#x2F;news-and-events&#x2F;news&#x2F;when-software-becomes-a-work-of-engineering" rel="nofollow">https:&#x2F;&#x2F;engineerscanada.ca&#x2F;news-and-events&#x2F;news&#x2F;when-softwar...</a>

There is value in predictability, even if it stems from someone else&#x27;s preferences.<p>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.<p>My home is from the 1950&#x27;s. Some wires go diagonally from top left to bottom right at the <i>other</i> side of the wall. We had great fun finding out where they were hiding.<p>Even if the new wires waste a lot more wiring and PVC tube, I vastly prefer them when redecorating or drilling holes.

I hate the expression &quot;best practice&quot;, it&#x27;s so, so often used by someone to justify applying cargo cult without actually understanding why.<p>&quot;Hey why are you having a try-catch there, it seems like it&#x27;s just gonna break our stack trace and we don&#x27;t even graciously recover from it&quot; - it&#x27;s best practice<p>&quot;Hey why are you using model&#x2F;view&#x2F;controller folders?&quot; - it&#x27;s best practice<p>&quot;Why are you building microservices?&quot; - best practice.<p>I got out of a code base with stylecop&#x27;s settings set to max and treated as errors. Trailing white spaces, mandatory comments on everything, etc. The only exceptions are file size and method size. Files are often in the thousands of lines, and methods can reach that as well. 10 levels of nested if&#x2F;else. So we&#x27;re in an unmanageable code base, but at least we don&#x27;t have trailing white spaces.<p>Most of the time it could be replaced by &quot;tradition&quot;, &quot;pattern&quot;, or &quot;the way I&#x27;ve seen others do&quot;. If it&#x27;s a tradition and most people agree to it, fine, might help with readability. If it&#x27;s pattern, fine, tell me why it&#x27;s applicable and helpful in our context. If you can&#x27;t actually explain <i>why</i> you&#x27;re doing something, maybe rethink it and educate yourself on the topic

&gt; <i>Java is infamous for its verbosity.</i> [...]<p>This paragraph highlights something I&#x27;ve been saying for ages.<p>Most criticism of Java needs to be directed towards Java programmers and not the language itself.<p>The language allows you to simply make a class. You&#x27;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.<p>Getters and Setters? You probably don&#x27;t need them. Classes <i>can</i> have public member variables.<p>Java programmers seem to have the hardest time understanding YAGNI.

Steven Sinofsky gave a talk and said something to the effect of, we&#x27;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 &quot;baseline&quot; knowledge that has yet to be established. I think it&#x27;s a good way to think about things.

Best 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.<p>&quot;Best practices&quot; in software engineering are usually about internal development processes and don&#x27;t have any verifiable connection to outcomes.<p>In other words, we have two entirely different things labeled with the same name. People who commonly use the phrase &quot;best practices&quot; for software are literally trying to confuse you and generally are not worth listening to.<p>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 &quot;professionals&quot; that do exactly that.<p>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&#x27;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.

Right, 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.<p>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 feel like at this point, comparaison between software engineers and civil engineers should fall under the &quot;does not gratify intellectual curiosity&quot; category. I haven&#x27;t seen anything interesting said about this topic since the article series &quot;are we really engineers?&quot; <a href="https:&#x2F;&#x2F;www.hillelwayne.com&#x2F;post&#x2F;are-we-really-engineers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.hillelwayne.com&#x2F;post&#x2F;are-we-really-engineers&#x2F;</a>.<p>&gt; At the end of the day, you wind up in a lot of fairly pointless arguments about tech stack and coding conventions that 99.9% of the time don’t make a bit of difference to the final product.<p>That&#x27;s a great conclusion.

&gt; You can’t do it “correctly” if “correct” is “whatever the guy who’s been here longer wants.”<p>To be honest, &quot;correctly&quot; is whatever actually works. But since we as an industry haven&#x27;t been around for a long time and don&#x27;t collectively know what actually works, it is simply the case that we defer to those who have comparatively more experience, so that we may get decent solutions now, as opposed to excellent ones later.<p>It took the ancient civilizations hundreds if not thousands of years to perfect architecture to a reasonable degree, where it&#x27;s possible to be fairly certain about the viability of most typical designs, as well as the tradeoffs that nonstandard ones might require.<p>Personally, i think that we&#x27;ll only be able to talk about what truly works and what doesn&#x27;t once the industry cools down - when there are new JS frameworks once a month or once a year as opposed to every day (or for any technology, really). When there are very few breaking framework changes, because the frameworks would finally be stable. When the primitives around doing web development, interfacing with devices and everything else have been distilled to their most usable possible forms. When a developer doesn&#x27;t need 10 languages or 20 frameworks to do their job, but can instead rely upon a few, after most others would have died off after a sort of singularity of languages.<p>That&#x27;s when useful certifications would be possible. That&#x27;s when estimates wouldn&#x27;t be guesswork. That&#x27;s when the education systems could actually prepare people fully for working in the industry. That&#x27;s when the development of projects wouldn&#x27;t be such Wild West, but instead would be a process with far higher quality, a true engineering discipline even at the expense of projects taking longer to actually develop, much like you don&#x27;t construct buildings in an ad hoc fashion.<p>Now, whether that will happen in a 100 years, a 1000 years or never, is another question entirely.

All the problems stated require more context:<p>- extract an interface or not -&gt; an interface can speed up compilation (under the right conditions)<p>- pass more or less arguments -&gt; how many call sites exist? What’s the performance difference? Would it complicate testing?<p>- testing -&gt; depends on what you’re building, when do you need it by, and how problematic a bug may be (and more)<p>The reason it looks like some random preference is because over time we naturally gravitate (or been told to do) what works, and we keep choosing it heuristically since a thorough analysis of the problem is too costly or impossible.<p>Civil engineering has a bunch of hard rules on have X slack here because people will die for such mistakes. But I suspect you use best practices for less high stake stuff (do we use this outlet configuration or this one?) (actual civil engineers are welcome to correct me)

Short answer: No, they&#x27;re not.<p>Longer answer: I&#x27;m confused by the examples given. Nothing there is a best practice IMO, they are only opinions.<p>This writer is confusing &quot;use git&quot; or more basically &quot;use version control&quot; with the how&#x27;s and why&#x27;s underneath. Everything beyond &quot;use it&quot; is an opinion, with multiple &quot;best&quot; options depending on your desired workflow or requirements.<p>Same for Java - the senior explained why this version of &quot;best&quot; is best for them, but the real best practice of &quot;define your interface as a contract&quot; is hidden behind these opinions.<p>Contrast this with the civil engineer used as an example, who might say &quot;use a safety factor of 3x rated weight for all fasteners&quot; as their best practice. Using fasteners rated at 2x is a violation of that, but using screws vs bolts vs adhesive are all opinions and depend on the particulars and preferences of whoever is doing the work.

The two aren&#x27;t mutually excusive. What I mean is, you can develop a preference for doing a software engineering task according to a best practice. Getting into the habit of using one or more time-tested practice(s) will only benefit you over time.<p>But, more fundamentally, what the author could have responded to their friend is: &quot;Yes, we do have a code of ethics and professional practice standards[0]. We do have well-researched best practices and a rich standardized body of knowledge we can use[2]. We do have formally adopted standards through IEEE, ISO and IEC[1].&quot;<p>I do get the sentiment behind the question though and personally wish we were more formally trained and held more rigorously to a professional set of standards. It does diminish the term &quot;Software Engineer&quot; as a engineering field when we use the title so loosely but (on some level) expect the same level of respect, pay and status as other engineers.<p>[0] <a href="https:&#x2F;&#x2F;ethics.acm.org&#x2F;code-of-ethics&#x2F;software-engineering-code&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ethics.acm.org&#x2F;code-of-ethics&#x2F;software-engineering-c...</a> [1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;ISO&#x2F;IEC_JTC_1&#x2F;SC_7" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;ISO&#x2F;IEC_JTC_1&#x2F;SC_7</a> [2] <a href="https:&#x2F;&#x2F;www.computer.org&#x2F;education&#x2F;bodies-of-knowledge&#x2F;software-engineering" rel="nofollow">https:&#x2F;&#x2F;www.computer.org&#x2F;education&#x2F;bodies-of-knowledge&#x2F;softw...</a>

After reading this article, the theory that comes to mind is that &quot;best practices&quot; not just developer preferences - rather, &quot;best practices&quot; is cargo culting by mediocre programmers, trying to copy techniques that a really skilled programmer once employed to do amazing things.<p>This is the part of the article that made me think this:<p>&gt;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.<p>This sounds like they&#x27;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&#x27;s not necessary. But I&#x27;m guessing neither side really knows how to use that to do amazing stuff.<p>Some programmers don&#x27;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.<p>That all sounds very mean, but if this is what&#x27;s actually going on, I&#x27;m not sure what the solution is. Maybe more focus on really impressive and amazing concrete projects, rather than just individual practices in isolation?

Yes and no.<p>Given the context of the authors ( and this also includes employment context, socioeconomic and personality factors for everyone involved ), the best practice is something that has been &quot;proved&quot; to work well.<p>So no, it&#x27;s not just a preference, but in practical terms many times it&#x27;s a preference that some people agree it worked ( in their context ).<p>And let&#x27;s not even talk about the &quot;best practices&quot; and technologies created just to sell you something. I think by now it&#x27;s not a secret that most &quot;developer evangelists&quot; or even &quot;famous&quot; developers are just people doing sales and marketing, some of them don&#x27;t even realize it such is their ego trip.

In some cases, perhaps, but the _state of the art_ is always evolving and a lot of it is informed by how people practice software engineering in the wild.<p><i>Professional Engineer</i> is a modern concept. In the United States it started in 1907. Sure we have been building irrigation systems for thousands of years but it wasn&#x27;t regulated by governments until recent history.<p>Until then it was a practice guarded by guilds and seen as a craft.<p>Software isn&#x27;t without its own history. The mathematicians and logicians had been working on it long before the first computing machine was built. We&#x27;ve known how to compute values for thousands of years.<p>Are we still in the craft&#x2F;guild phase of the discipline? I don&#x27;t think so. There are professional engineering organizations around the world that are certifying software engineers. If that is all that is required you can apply today.<p>The missing piece is that it&#x27;s not required by governments around the world to have any professional affiliation or certification to practice programming professionally. Some argue this is a good thing as it keeps the playing field level. Others argue its bad as it enables profit-motivated companies to cut corners that harm businesses and users.<p>But as far as best practices go, as long as there are enough people practising them across the industry, then it&#x27;s not simply a <i>preference</i>. A good guide on this is the SWEBOK [0] published by the IEEE which attempts to catalogue these practices in a living document that gets updated as the <i>state of the art</i> develops.<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Software_Engineering_Body_of_Knowledge" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Software_Engineering_Body_of_K...</a>

Make the simplest thing you possibly can, write lots of software tests and keep in mind that your code is a piece of communication to the next developer, like a story. Everything else is just vanity or preferences.

I get your friend, and there&#x27;s another point he can make: Imagine a world with self taught Civil Engineers.

Aren&#x27;t best practices things like &quot;don&#x27;t roll your own crypto if you can avoid it&quot;, &quot;store your code in version control&quot;, or &quot;write down migrations as well as up migrations&quot;? These are all choices where the right option has been absorbed into the craft.<p>Civil engineering best practices are written in blood, but I think software engineering best practices can be stretched to include sweat and tears too.

Developers end up at local maxima because a whole bunch of practices add up to a working system. It&#x27;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&#x27;s all about the system where they all work together.<p>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&#x27;t apply. We&#x27;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&#x27;s a mismatch between the social environment and the likely project management approach. But we&#x27;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, &quot;You shouldn&#x27;t use it?&quot; Why does it work so well in Rails?<p>IMO it&#x27;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&#x27;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 &quot;readable&quot; styles and not worry so much about side effects (since there are few).<p>[0] <a href="http:&#x2F;&#x2F;number-none.com&#x2F;blow&#x2F;john_carmack_on_inlined_code.html" rel="nofollow">http:&#x2F;&#x2F;number-none.com&#x2F;blow&#x2F;john_carmack_on_inlined_code.htm...</a><p>[1] <a href="https:&#x2F;&#x2F;www.martinfowler.com&#x2F;bliki&#x2F;FunctionLength.html" rel="nofollow">https:&#x2F;&#x2F;www.martinfowler.com&#x2F;bliki&#x2F;FunctionLength.html</a>

As I read this I&#x27;m building a distribution of a web framework that eliminates block templates and will only have one page template (for the head HTML). I&#x27;m gonna have CSS generation and upload built in the CMS as well (tailwind or tachyons only).<p>I&#x27;m sure there will be howls of &quot;you can&#x27;t let them put code in the database!&quot;<p>Why not? It&#x27;s their (the customer&#x27;s) database and their web service, after all. You can do all sorts of validation on a form input and a database field (like with Tidy and Bleach in my case with Python). Can&#x27;t do any on a plain text template file.<p>But &quot;separation of concerns!&quot;<p>For who? It&#x27;s always been bad practice in my opinion to assume that not only do end users have on-staff development, or contract development, but that they have <i>multiple tiers</i> of it which need lines drawn between the duties of each. Who says everyone who needs custom software or custom web services is an IBM-sized conglomerate with multiple departments full of software developers? Why can&#x27;t a mom and pop restaurant have a nice website and a nice phone app? Because they don&#x27;t want to learn to use javascript, webpack, npm, git, and an IDE? Is that the only reason why?<p>The least accessible (in a physical sense) parts of web development are the parts that a customer might do themselves (CSS and HTML). I will not believe there is a good reason for that other than software developers trying to talk themselves into more jobs and more contracts.

I hope at least that we&#x27;re in a phase of the profession where we&#x27;re &quot;discovering&quot; the actual best practices.<p>There have been a lot of best practices that have been hypothesized over time: OOP, functional programming, unit testing, generative testing, formal analysis, strict typing, weak typing, etc.<p>And all these as-of-yet unfounded hypotheses are important! You&#x27;ve got to have a theory of how something works before you can prove that it does. Hopefully we can start to devise those proofs.

&quot;So what are these rituals for?&quot;<p>&quot;Some are purely ritual, but some are there so that we can guard this dimension from horrors that live within!&quot;<p>&quot;Uh, I guess we should at least do the latter?&quot;<p>&quot;Oh? You can tell the difference? That&#x27;s great!&quot;<p>-- Girl Genius

In your example, read the spring manual. You need the inference to help spring generate proxies for your service class. You could use cglib to remove this requirement but it&#x27;s the way the spring API has been for ages. Also using an interface let&#x27;s you easily mock things out and write dummy test implementations. Pretty valuable.

A lot of &quot;best practices&quot; are developers who make code complex in order to attain some level of architectural purity for its own sake.<p>An example of this I recently experienced was trying to understand and debug what should have been a simple integration app, but where a ton of injected commands and queries were used to implement the functionality. Following the logic was painful as the code was completely atomized for no particular reason. Worse, real-world concerns, like proper logging, were ignored.<p>I hate to call this an &quot;autism tax&quot;, but perhaps there&#x27;s something to the term: many intelligent developers, especially left unsupervised, tend to pursue highly abstract solutions, to what should be straightforward problems in order to satisfy a compulsion for order and symmetry.

I had a principal engineer who wouldn’t use the term “best practices”. Instead, he called them “proven practices.” I’ve adopted that term myself, because it is much more accurate- there is a body of knowledge on how to build software well, but it’s a tool kit not an instruction manual.<p>There also really is software engineering that goes on- I work in an org that does extensive analysis, testing, and validation of firmware before it is rolled out. It’s a real thing. That being said, so is cranking out a CRUD web app with zero testing to make our PMs data collection tasks easier. It’s all on a continuum. The key trick for software “engineering” versus just development is knowing where in the continuum a given project needs to be and what tools are appropriate in that context.

Lots of Java Frameworks (definitely Spring) will generate wrapper classes for your code to handle things like method level authorization, pre&#x2F;post method logging, Exception transformation. This is generally termed &quot;Aspect Oriented Programming&quot;. This is exactly whats going on with Spring&#x27;s @Service annotation. In order for you to still be able to call your methods even though the class will be some sort of proxy at runtime, an Interface is required. It may seem silly but it all makes perfect sense when you understand whats going on.<p>Edit: Surprised I haven&#x27;t seen this mentioned in any other comments. I had thought this was pretty common knowledge, at least amongst people with Java experience.

What code would you rather maintain:<p><pre><code> &#x2F;&#x2F; A const int giraffe = 1 + 1 + 1 + 1 + 1; &#x2F;&#x2F; B const int number = 5; </code></pre> At some moment, you will meet some disagreeable person that will say they are the same and it doesn&#x27;t matter which one you pick.<p>A is similar to Roman numerals. We all know that Roman numerals are no longer used for most purposes and were replaced by the numeral system we currently use. Not only the new numeral system is more convenient for various reasons but it allowed people to advance math further. So A is better than B in that sense.<p>Then, A uses an identifier that doesn&#x27;t represent its value. We can also say it&#x27;s bad because of that reason.<p>You can try to seek ways to compare and improve code. Not all of them will be effective, but at least you will be trying. That is better than being that disagreeable, nihilistic guy that thinks that everything is subjective and relative and won&#x27;t agree with anything you say.<p>You have to learn how to treat your code with respect and prevent it from becoming a tech debt dumpster.<p>There is code that is objectively bad. And you will know when you try to maintain, debug or profile it, or when you have to explain it to someone else. Or when it keeps breaking over and over again and many defects are connected with it. Or when it becomes a product limitation and you have to apologize to customers about it.

To some extend best practices are just developer preferences, but some best practices are also due to experience which has shown alternatives to attract problems down the lane.<p>Personally I think the most important thing is to agree within a project, what style and what practices to follow, so everyone is going in the same direction. This should in my opinion make the code more maintainable and extensible, due to the reduction in cognitive overload for the developers involved.

I don&#x27;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.<p>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.<p>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&#x27;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&#x27;t have the potential to harm people, like houses and bridges have. So you have less regulations.<p>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.<p>Most engineering products only rely on best practice and the way the company does it since years, from experience. There is no &quot;right&quot; solution, neither in civil-, nor in software-, nor in engineering in general.

Well the choices should be based on data, does method 1 or method 2 result in code which functions longer without needing to be fixed, or updated.<p>There _IS_ data about some of this, but the results frequently go against the opinions of various people, so they are discounted. And then there is the problem that the industry as a whole has a tendency to run away from old&#x2F;stale&#x2F;well understood&#x2F;etc technologies in support of untested new products. Which is how you get the cool language churn. You can just look at the last 20 years of server side web development, php, ruby, python, javascript, were all the &quot;best choice&quot; at one point or another, only to be pushed to the sidelines when they were discovered to be sub-optimal in some way.<p>So, its like the C&#x2F;java&#x2F;etc brace problem. There were a fair number of actual studies showing that matched brace styles seem to result in fewer bugs back in the 1990&#x27;s, yet overwhelmingly the opensource community rejects that in nearly every single project regardless of language. Why? Presumably its just personal preference going back to the old days of 80x25 tty&#x27;s where whitespace was at a premium, same as the 80 column limits many projects employ.

A big issue in this industry is that folks do things like if no one else had done them before, reinventing the wheel continually. It feels like it evolves fast, but really, it&#x27;s going in slow motion, because we&#x27;re constantly starting over.<p>It doesn&#x27;t matter if someone, or a group of people, spent years researching a topic: even given an extremely similar situation with similar resources and constraints, an engineer right out of school will still feel compelled to try and solve the problem anew.<p>Part of the issue is that we&#x27;re very bad at identifying constraints and context, and thus it&#x27;s really hard to apply pre-existing solutions. Eg: people trying to apply concepts developed by large FAANG-style companies in a startup.<p>Part of it though, is sheer arrogance. Everyone feel like they know better. There&#x27;s also a bit of &quot;playing programmer&quot; going on: folks do a lot of things because they find them more fun, even if it was somehow objectively a worse solution (and they knew it). Because software engineers are in such high demand, people above are afraid to drop the hammer. Concept such as team or individual autonomy are put above the global maximum of the business. This autonomy and freedom is justified by saying it drives innovation, but you&#x27;re not innovating if you&#x27;re constantly starting over. For example, while modern languages do have some cool new features, we also keep reinventing the tooling, editors and debuggers around them, which drives progress in those areas to a crawl.<p>All around, there&#x27;s a balance between solidifying some concepts, vs continuing to innovate. Right now we&#x27;re leaning a bit too hard toward chaos, and the industry would benefit a little from letting things mature.

I think there is just some semantic confusion here.<p>I think a &quot;best practice&quot; should be a practice that is good to apply across a certain problem domain (regardless of where you work or what dev team you are part of).<p>And there are coding styles&#x2F;guidelines which can apply only to a specific dev group or codebase. They can often be arbitrary, in the sense where it would be fine to do it in different ways, but one is chosen, for consistency (to promote maintainability&#x2F;readability). They can be <i>one way</i> to achieve a best practice.<p>Day to day, it&#x27;s probably fine to loosely call all these &quot;best practices&quot; since you apply them the same. But it is also sometimes useful to make the distinction, e..g, so you understand <i>why</i> a certain practice is being used.<p>The first example is a coding style, and a judgement call. The underlying &quot;best practice&quot; is to separate interface from implementation. There are various other ways to do that, of course, and need not be done like this. (Personally, I find this practice a little &quot;enterprise-y&quot;, which I consider an insult.)<p>The example about version control also depends on the process and practice of the dev group.

Skimming all of these comments I think that creating software remains more of a craft than an engineering discipline. Not that that’s a bad thing, in that it permits creativity. And for most cases, engineering-level rigor isn’t worth the effort. As Tom West said in Soul “Not everything worth doing is worth doing well.”<p>Sadly, this approach seems to have been used in the interface software of my RAV4.

The issue here is that people abuse the term and call many things and anything a &quot;best practice&quot;.<p>An actual best practice is based on objective criteria and experience, and can be shown to lead to better outcomes over the alternatives.<p>If that&#x27;s not the case, then it is just a preference, indeed.<p>For instance, version control is a best practice. It objectively improves software development. So is unit testing, etc.

<i>&gt;“How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is? The parallel he drew was to another friend who’s a Civil Engineer. His friend had to be state certified ”</i><p>That friend simply didn&#x27;t realize that &quot;engineer&quot; has different semantics with different historical evolution of word usage:<p>(1) <i>&quot;professional engineer&quot;</i> -- as in state license board and certification e.g. civil engineer<p>(2) <i>&quot;engineer&quot;</i> as a descriptive modifier -- e.g. &quot;software engineer&quot; and also some non-programming examples such as &quot;audio engineer&quot;, &quot;video engineer&quot;, &quot;supply chain engineer&quot;: <a href="https:&#x2F;&#x2F;www.google.com&#x2F;search?q=%22supply+chain+engineer%22" rel="nofollow">https:&#x2F;&#x2F;www.google.com&#x2F;search?q=%22supply+chain+engineer%22</a><p>We could ask a similar question the friend asked: How can there be a &quot;supply chain engineer&quot; when there are no governing bodies for &quot;supply chain certification&quot; ?!?<p>It&#x27;s because some people like to concatenate <i>&quot;engineer&quot;</i> at the end of a job role and others adopt the label and the usage gains wide currency. On the other hand, &quot;dessert pastry engineer&quot; hasn&#x27;t really caught on so creating a fancier title doesn&#x27;t always get accepted.<p>Back in the old days (1960s &amp; 70s), the job titles of programmers on org charts -- especially at <i>non-software</i> companies like banks using COBOL, etc -- was &quot;PROGRAMMER I&quot;, &quot;PROGRAMMER II&quot;, etc. The &quot;software engineer&quot; seemed to be mostly popularized by <i>software-focused</i> companies like Microsoft, Silicon Valley. But now, even old companies like banks where coding is a cost-center instead of profit-center also have &quot;engineer&quot; in programming job titles.

&gt; How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is?<p>So the world had no engineers before the creation of governing bodies? That doesn&#x27;t sound right to me. Thus, I think this person&#x27;s definition needs some tweaking.

Yes...?? And what&#x27;s wrong with that?<p>&quot;Best Practices&quot; means - given this problem set, these other engineers have tried a number of ideas and put together a framework, idea, code, whatever that represents a *good enough* solution.<p>There is no such thing as literal best, greatest, perfect. We&#x27;re all just balancing tradeoffs in the &quot;best&quot; way we can.<p>For teams, consistency is more important than cleverness. If something needs to be &quot;clever&quot; then it is important enough to become consistently used because if the person who built the &quot;clever&quot; thing leaves, it becomes expensive to maintain it.<p>That&#x27;s what &quot;best practices&quot; are, they are a consistent set methods that enough people have tried them that allows you to &quot;stand on the shoulder of giants&quot; and focus on more critical problems.

I found this video on the topic very compelling: Intro to Empirical Software Engineering: What We Know We Don&#x27;t Know • Hillel Wayne • GOTO 2019: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=WELBnE33dpY" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=WELBnE33dpY</a>

The only objective thing for best practice is simplification. Problem with loose coupling, OOP etc... is that a lot of it sounds like &quot;done&quot; right but becomes complicated over time - even though it might be a good idea. So only &quot;KPI&quot; for best practice should be simplicity over time.

The best best practices I&#x27;ve heard usually have stories behind them. Someone did or didn&#x27;t do X, and bad thing Y happened. Therefore we do or don&#x27;t do X in the hopes of avoiding Y again.<p>The danger is that X keeps happening without the story of Y also being passed along; otherwise it turns into the Five Monkeys problem (<a href="https:&#x2F;&#x2F;intersol.ca&#x2F;news&#x2F;organizational-culture-and-the-5-monkeys-experiment&#x2F;" rel="nofollow">https:&#x2F;&#x2F;intersol.ca&#x2F;news&#x2F;organizational-culture-and-the-5-mo...</a>).<p>I&#x27;m not disagreeing with the author&#x27;s friend&#x27;s point. But at least if there&#x27;s a story attached to the practice, then it&#x27;s less of an appeal to authority and more of collective wisdom that can continue to evolve.

There are people on both side arguing that &quot;best practices&quot; are good and bad. But that&#x27;s not the point.<p>Best practices are necessary. The value of &quot;best practices&quot; rests not on whether it is good. Its value is that there is an enforced standard across a business&#x2F;organization. The existence of a standard (and recommended way) helps smooth out the execution&#x2F;operation. In software engineering, that means easier refactoring, easier migration, easier tooling development, easier training, easier for people to move around within an organization instead of moving out...<p>I&#x27;d recommend any organization to find, install and periodically improve their &quot;best practices&quot;. Just the virtue of their existence is a net positive to the business.

&gt;How can Software Engineers call themselves engineers<p>I always wondered the same thing, even now, az a so-called Lead Software Engineer. Frankly I call myself a programmer and that&#x27;s it, maybe a &quot;manager of sorts&quot; now that I&#x27;m a &quot;lead&quot;. I don&#x27;t want to assume what others are doing, maybe engineering level work, but I&#x27;m rather an overpriced jack of all trades myself, who happened to have a nicely paying trade as a hobby, and an agreeable personality to sell it.<p>Architect is another glorified software position. Millenia of architects pushing the limits of human technology, often bearing huge responsibility for their plans, just so that later I can come in, advise my client to use the AWS vendor lock-in vehicle, and call myself an architect.

Right now I am working on converting a front end application written in angualar&#x2F;typescript using a monorepo technology called nx.dev into a micro-frontend architecture. All the teams that have been contributing code to the project never bothered to use nx in the way that it was intended and disabled linting for the entire project. The thing is if people had followed the linting rules it would have made my life 1000x times easier because now I have to take a scalpel to the monolith they&#x27;ve made and break it down into smaller parts. Linting rules would have told them to respect module boundaries and warned about circular dependencies. Now I have to clean up the mess.

There&#x27;s all kinds of non mission-critical software that gets made with little life&#x2F;death consequence on <i>how</i> it gets made. There doesn&#x27;t seem to be the same notion of the &quot;bridge that barely stands&quot; in software either since compute power can be thrown at something way cheaper than a rewrite. Thus, when it comes to the people that make software, there&#x27;s a wild amount of interpretation on what &quot;good&quot; means and here we are.<p>And if I can opine on your Spring Boot example, unit testing can <i>sometimes</i> be easier for mock purposes if you have a set of interfaces (vs concrete classes) to work with.

Vernor Vinge uses the term &quot;Programmer-Achaeologist&quot;, which feels appropriate to any time we&#x27;re doing software maintenance. If I&#x27;m truly creating something new I&#x27;d go with &quot;Software-Alchemist&quot; since the practice feels much more in line with the efforts of alchemists to fumblingly come to grips with actual chemistry than with modern engineering.<p>After reading about practices at JPL during the development of Curiosity, and the earlier work on Apollo (just two examples) I do think there is such a thing as an engineering practice of software development. I just don&#x27;t think most of us are using it.

&gt; 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.<p>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 code. Using the interface for the new code made it much simpler to use a radically different implementation, and also made devs think about what the real interface should be, vs just coupling to some implementation.

I agree with the author, but saying &quot;best practice&quot; in a group discussion is frequently used to make someone&#x27;s position sound more official. &quot;Industry standard&quot; gets used the same way. Some people think that saying these things is like pressing an &quot;I get what I want&quot; button.<p>I have to fight the urge to ask for citations whenever I see someone pull out one of these chestnuts. Rather than be contentious, I just think about whether or not their argument <i>needs</i> the extra oomph of authority that they&#x27;re trying to give it. My hope is that not rewarding disingenuity reduces its power.

&gt; 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.<p>Reason I avoid working in Java and especially the &quot;senior java engineers&quot;.<p>&gt; The logic from the senior engineer was that the interface represented the “contract” and the class the business logic.<p>This is basically religious dogma

I&#x27;ve never had the title &quot;Software Engineer&quot;. It&#x27;s always been &quot;Software Developer&quot;. And that feels appropriate. I write business software. Nobody dies if it fails. The monetary damages are generally small (in absolute terms) and problems easily rectified (relative to fixing a failed bridge).<p>I would expect a software engineer to be working on safety-critical systems. Power grid control, military applications, etc. And I hope there&#x27;s a massive amount more rigor applied to their work than there is to mine.

Pretty much. Just averaged over sufficiently large number of devolpers. And since the developers are the one that the code is read by then it&#x27;s perfectly reasonable.

There are probably a ton of definitions of what a best practice is in SE.<p>When it comes to code, I like to think best practices are those that make code easier to change and understand, without significantly compromising performance.<p>Developers who mainly target high performance with their code probably think my best practices suck, and so on.<p>At a practical level, what really matters is consensus within an organization. Organizations where people hold incompatible ideas of what good engineering is are basically doomed.

A LOT of coding style, abstraction style, function vs inline is just preferences. This is what makes code reviews hard. Both the author and reviewer can easily fall into the trap of trying to &quot;correct&quot; the other person - without realizing that they are merely forcing preferences on the other.<p>That said, it is ok to write down some preferences as a team&#x2F;org standard that everyone can follow.<p>Just don&#x27;t make the job a lawyers attempt at software engineering.

&gt; At the end of the day, you wind up in a lot of fairly pointless arguments about tech stack and coding conventions that 99.9% of the time don’t make a bit of difference to the final product.<p>99.9% of the time they do, maybe you don&#x27;t see them functionally and visually, but probably you aren&#x27;t measuring security flaws, performance and specially ease of maintenance which goes unnoticed most of the time...

Software engineering seems partially creative partially technical - so on the creative parts, yes absolutely teams should self define their preferences. Scrum vs agile vs whatever else IMO should be a team&#x2F;org preference. However like someone else said some engineering has to be liable for criminal prosecution in some cases. So you need some practices to be enforced.

Some certainly are, many are not.<p>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&#x27;re practicing the &quot;best practices&quot;.<p>Whereas, if you don&#x27;t follow some &quot;best practices&quot; and they&#x27;re still clear to others, they are just &quot;developer preferences&quot;.

&quot;Standards&quot; cover what the system does. &quot;Best practices&quot; cover how it&#x27;s done.<p>Best practices (generally opinions based on reasoning): language choice, KISS&#x2F;DRY&#x2F;YAGNI, linter rules, unit tests, static vs dynamic linking.<p>Standards (de-facto, at least): ISO, RFCs, PCI, and whatever is relevant for the industry the solution is for.

&quot;best practices&quot; = &quot;common practices&quot; in practice.<p>Not necessarily best. Best practices you get when you apply a darwinian approach in your org and try out several techniques before selecting the best. What is called best practices too often is a name for &quot;we&#x27;ve done it this way since the beginning&quot;.

&gt; My housemate the other day asked me something to the effect of “How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is?”<p>There sure is, that is what countries that have Professional Engineering titles have.

I&#x27;d say that a lot of devs do have a hard time distinguishing &quot;best practices&quot; vs &quot;the way I like to code&quot;. It&#x27;s also tough because many of the motivated devs who can push these initiatives through need help with the sometimes subtle difference.

As someone who has a liberal arts background, software engineering has a lot more in common with writing than most admit. Sure there is grammar and syntax but good writing can be as varied from William Shakespeare to Stephen King. Same with software writing.

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

In contradiction with the first paragraph, there are definitely fields of software engineering with external regulation, auditors, etc. I&#x27;m thinking of the banking sector and realtime critical software, like in avionics and such.

&gt; Are Software Engineering “best practices” just developer preferences?<p>Some are, some aren&#x27;t. Some are good practices but the state of the art evolves and better practices are uncovered.<p>And it&#x27;s really had to tell the differences. it&#x27;s a young field.

I&#x27;ve always used &quot;best practices&quot; as a nicer way of saying &quot;commonly accepted&quot;. It&#x27;s not really developer preferences -- there are a number of best practices that I don&#x27;t prefer as a developer.

IIRC, the book Code Complete talks about best practices and contains links to studies when they apply to those practices. I might be wrong, it&#x27;s been a while since I read the book and I can&#x27;t get to it right now.

Having an interface for a single implementation is just redundant. A class already has an interface - it&#x27;s public API.<p>Other than that I agree, most &quot;best practices&quot; are subjective and boil down to personal preference.

Codified Software Best Practices have been around for decades.<p>Steve McConnell (<i>Code Complete, Rapid Development,</i> etc.)[0] used to be the Best Practices Editor for the IEEE.<p>It’s just as the author mentioned; no teeth. Companies are happy to pay for slapdash work (thus, undermining the drive to do good work), and employment tests often don’t really have much bearing on real-world engineering.<p>I’ve spent decades refining techniques and habits that I think work quite well. I occasionally write them down[1], which I find helpful in understanding them better.<p>[0] <a href="https:&#x2F;&#x2F;stevemcconnell.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;stevemcconnell.com&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;" rel="nofollow">https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;</a>

Engineering is the wrong classification. I think the problem is it&#x27;s new enough that people try to relate it to other disciplines. Coding is just its own thing.

I consciously use good practices as it leaves the door open to discussion and is not a strong appeal to authority.<p>The other one I’m not a fan is industry standard practice.

If the entire Object Oriented and design patterns and Martin Fowler fan boys could read, they would be very angry.

Is there really a difference, if more friction for developers == less productivity, less happy developers, and so on?

Best practices create a shared experience that can help get you out of trouble when that practice was a bad decision.

It’s best practice to apply best practices when it makes sense.<p>The catch? Knowing when it makes sense requires experience ;)

I can&#x27;t imagine someone arguing that avoiding tight coupling is a personal preference.

Or lowest common denominator, stuff you want get in trouble for doing, pablum?

Are civil engineering &quot;best practices&quot; just legal preferences?

It doesn&#x27;t really matter to me...<p>(as long as tabs stops&#x2F;indent are 4)

I&#x27;m pretty sure that most people consider &quot;software engineer&quot; to be just a fake title that makes business cards look fancier... sort of like referring to a janitor&#x2F;custodian as a &quot;sanitation engineer&quot;.

The phrase “best practice” is a sure fire way to signal “I don’t know what I’m talking about.” A lot of times these best practices are really good ideas. But misapplying them by rote can be more dangerous than ignoring them.

No, they are management&#x27;s developer preferences.

Without empirical evidence, who knows what they are?

There are no solutions, only tradeoffs

best practices are programming style convergence, which helps estimating software in my opinion.

The answer is not binary.

The answer is not binary

I am all against standards and engineering boards defining what is right and what is wrong, but at the same time I also favor software developers being held civil and criminal responsibilities for the outcome of their work. It is pretty hard to have the second without the first, so here I am at a crossroads.

&quot;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.<p>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.&quot;<p>I&#x27;ve argued for awhile now that Software Engineering with a big E should be licensed and regulated the same as any other Engineering discipline. Not all software is low stakes and fast changing. In fact I&#x27;d argue the most important software is never that. software for control systems, avionics, cars etc are very high stakes and have no reason to iterate beyond what is needed to interface with changing hardware. I think if software engineers had to be licensed to work on such things then those 737s wouldn&#x27;t have fallen out of the sky and Tesla wouldn&#x27;t be allowed to beta test self driving cars on public roads.<p>To those who ask what do you now call software engineers who don&#x27;t work on those things, you are programmers. Or if you prefer a less formal term, coders. Engineer is a powerful word and I don&#x27;t like how the we the IT industry have appropriated it for less critical tasks.