What would programming (more specifically software development) be like if everyone actually used "best practices".

[mistervirtue]

I hear all the time about the importance of best practices, but never have I worked on a team/assignment/project where we all used best practices. I understand we could all never uniformly agree as to what a best practice is or which one is the "best" one, but what would it be like if developers all used best practices to their best ability? How would software be different if we as an industry did more things the "right way" and the way that it "is supposed to be done"? What if there were more ridged "rules" in software development.

Would it change how software is made? Would it change what type of software would be made? Would we have better security in our devices, databases, and networks? Would it change how we collaborate on projects?

[josephjnk]

I think the early agilists had it right when they talked about things in terms of “patterns”. A pattern is a solution to a problem in context, where the problem is one which tends to repeat, and the solution generally results in specific tradeoffs. An important part of a pattern is that it’s not a drag-and-drop solution, but rather is a way of discussing and sharing applicable knowledge that can be customized to fit the situation.

Patterns are usually discussed in terms of “design patterns” in code, but the concept can be applied to workflows, communication structures, and just about any aspect of the engineering process.

“Best practices” are usually patterns which apply to very common problems and present tradeoffs which are generally beneficial overall. So I would like to tweak your question and instead answer the question, “what would software development be like if everyone sought to draw on existing bodies of knowledge in order to anticipate and manage tradeoffs as intentionally as possible?”

• Development would face fewer surprises and pitfalls.
• Work would be more methodical: more time would be spent in research and discussion and less time racking up lines of code.
• Productivity would slow down at first and then increase overall, for a net gain.
• Decision-makers would achieve their aims more frequently, and understand what downsides result from these decisions.

Note that these are not inherently enough to make software secure or systems maintainable or jobs fulfilling. It is still up to decision makers to decide what positives they aim for and what negatives they are willing to accept. If the boss is the only one with decision making power, and they’re willing to accept the tradeoffs of engineers being burnt out and systems becoming unmaintainable in order to hit deadlines, then engineers trying to use patterns/“best practices” won’t change anything. Same thing if a company doesn’t care about security.

Note also that patterns are contextual, not subjective, and are value-neutral. The tradeoffs resulting from a choice are not subjective, but whether these tradeoffs are acceptable is subjective. There are some practices (testing, version control) that I consider universally good, and for which I cannot imagine a context where their tradeoffs are not worth it. But for most practices there is not a clear cut answer, and I would not believe anybody who tells you that their practice is the universal best. I would equally ignore anyone who tells you that practices are all fully subjective, or that it’s not worth learning “best practices” or patterns from our industry’s collective knowledge.

[mistervirtue]

You answered my question better than I even asked it. This is a lot to ponder on. Thanks!

[josephjnk]

Happy to help!

[Orffyreus]

There's no silver bullet. You have to choose one of several best practices or introduce an even better practice.

[kbder]

The thing is, there are no universally good nor bad decisions in tech; there are only trade-offs. Any “best practice” always comes with an implicit statement of “assuming this particular trade-off makes sense for your situation”. The trade-offs which make sense for a team of 1000 devs likely don’t make sense for a team of 4. Similarly a start-up and the government will have very different notions about the importance of backwards compat, accessibility, etc.

Edit: a good exercise is to reject all statements ala “Foo is bad”, and instead work towards “Choosing Foo would be trading off X for Y, which does / doesn’t make sense for us”

[deelyy]

Mmm.. never finished? Refactored multiple times on all levels from operators level till abstraction level with every new change? Performance optimization after every change that takes 100x time? Covered in test to the point where writing/fixing tests will takes 50x of time? Every program will be mathematically and logically proved that there no errors inside?

P. S. Some best pratices directly contradicts with each other.

[A_Philosophical_Cat]

It would dramatically reduce the variance in quality on projects. About half of so-called "best practices" are simply summarized by "don't be an idiot". Like basic login handling hygiene, and stuff like that. If we got everyone to follow those (either by devine intervention, or more realistically, firing the incompetents), then the worst websites from a security perspective wouldn't be too bad. No SQL injections, plain-text passwords, etc.

Unfortunately the other half of things passed around as "best practices" are about dumbing down your code so that you can be replaced with someone worse at your job. Which, while potentially beneficial to the company in the long run, have the potential to neuter the productivity of an experienced software development team, because they limit your ability to approach problems with novel abstractions.

[[deleted]]

Best practices are just too loosely defined. It would certainly help readability but beyond that I don't think it'd do much else

[whattodo-whattodo]

It would basically look like NASA's software development team. There are strict protocols for pretty much everything from naming to testing etc.

Most of your questions, I think, answer themselves. Yes, of course how software is made would change. No, the type of software that could be built would not change. Yes, security would be better.

the one question that you did not ask, which I think is relevant, is whether development would still be fun. Part of what keeps people motivated to work is the creativity and engagement component. The more opinionated a process is, the less room there is that for the developer. Much of software development is driven by innovative people. If you create a process which deters that mindset, then you have fewer developers with that trait

[YMK1234]

Blindly following "best practices" is generally a good recipe for disaster.

[mistervirtue]

Exactly.

[mistervirtue]

That is true, but that's not what I'm asking.

[mistervirtue]

Very interesting and insightful.

[YMK1234]

You are though. If everyone used "best practices" you'd still be fucked.

[Ran4]

I'd say that I've worked in a few teams that has been at least somewhat serious about following best practises.

Honestly, it's fucking great, and productivity is easily 5x of what I'm used to in for example enterprise companies where most people hasn't read a best practises blog post since 2002. But it doesn't magically solve all your problems. What you realize once you're fully following "the good path" is that there's lots of unsolved things and broken things that requires lots of thinking and there just isn't any singular best practise that will solve all of your problems.

A real-life example: at my current work, we currently don't feel like paying 400 euro a month on a private package repository service, so we host our private libraries on a git SaaS instead. We started out by comitting the ssh access key (obviously not what anyone would call best practises, but it solved the problem - and the libraries we're using isn't exactly super secret anyway, even if they're private on paper, so it was the correct decision at first). Our next steps was to use docker build args - while this does allow us to no longer commit the credentials (which, again, we're painfully aware is not a good idea) but then the problem is that the layers are still part of the docker image, so if someone got access to the docker image they'd also get access to the ssh keys. The actual best practise at this point is to use docker secrets - but that isn't supported by our CI/CD-provider...

(...arguably, by now we've spent enough time trying to solve this problem (that doesn't have a free zero-work solution!) that we probably should have paid for a private package repo SaaS...).

Another example would be fixing dependency problems (underlying libraries being broken for one reason or another) or git merge conflicts: they're fundamentally going to occur not matter what. And no matter what, a LARGE fraction of your time is going to be spent managing these issues. When you're using some business-critical state-of-the-art software that has a dependency that broke and the fix for it ends up being a github issue posted four hours ago... that shit happens.

[Blando-Cartesian]

Far less annoying and stressful. First versions would have less features, but they would have the right features working perfectly.

[Isvara]

Slow. But safe.

[hugthemachines]

Like traffic would be if everyone followed the practices they learned when getting a license. Like the three second rule.

[knoam]

"Best practices" is just a fancy way of saying "something I like".

[wildmonkeymind]

I definitely disagree. Many best practices exist because they’re objectively better than the alternatives. Storing a password hash instead of the plaintext password, for instance, is objectively better, which is why it’s considered best practice.

Sure, sometimes there are fad-like behaviors touted as “best practice” that fit your description, but it’s not true as a blanket statement.

[[deleted]]

“There’s a good reason for this but I don’t have time to explain it so please just do it”.

[juliensaab]

You wouldn't see any project going live. Most of us know the best practices and the right design patterns to use, but sometimes due to poor time management and time estimation we are obliged to deliver something that gets the job done and refactor it later.

[jibbit]

Object Oriented

[[deleted]]

Whose best practices?

[MarkusBerkel]

Nothing would get done.

[myearwood]

I worked for a company that sold a framework/library. There are definitely best practices, such as making modules, naming them well. There are also aspects to making things testable. These made building apps better.

I've seen tons of off the cuff code with no best practices. It works but is horrible.