6 ms·

Do Best Practices Matter?

31 points by jshchnz 3y ago

al_borland 3y ago
I think this is a complicated issue. While I think it’s important to maintain focus on the actual point of software (delivering something useful to people), it’s important to not completely ignore the shoulders of the giants who came before us, to avoid learning old lessons the hardest, and avoid solving already solved problems. I think Tesla is guilty of this when it comes to their manufacturing. Elon wants to do everything from first principles to remove waste, meanwhile the “old guys” designed and rolled out competitive products to mass production, while Tesla struggled for years. Experience matters, but doesn’t mean anything if the playbook keeps getting thrown out.
- philipov 2y ago
  It's because rather than understanding that waste is eliminated through decades of practice optimizing a single process, Musk thinks it's eliminated by getting rid of stupid people who prioritize useless things like safety. It's a teenager's perspective on what's wrong with the world, "Why don't they just do it better?"
greymalik 2y ago
> The best practices we followed often felt like cargo cult programming. Best practices are cargo culting if they aren't adapted to the local context.
- eddd-ddde 2y ago
  Also, is cargo cult really that bad if it helps us stick with consistency?
  - TehShrike 2y ago
    "consistency" isn't beneficial unless it makes you better at shipping something useful
    - bluefirebrand 2y ago
      I struggle to think of any time when consistency would not make you better at shipping something useful A codebase with consistent styles and patterns is easier to work on than a chaotic codebase, it would definitely make you better at shipping And so on
      - eddd-ddde 2y ago
        This was my line of thinking when making the comment. Obviously there has to be some balance, but in general I'm a fan of consistency, even if I'm not a big fan of the things we are being consistent on.
        bluefirebrand 2y ago
        I think the problem with cargo culting isn't usually the stuff the cargo cult preaches It's the constant churn of dropping the current thing for the new cargo cult whenever it comes along. Cargo culting destroys consistency by constantly seeking the next new hotness
      - dolni 2y ago
        What if everything were written in C? Or Python? Or Java? We'd have massive consistency across the software industry and yet that would be an absolutely terrible idea.
      - TehShrike 2y ago
        I've seen codebases that were consistent in e.g. copy/pasting a meaningless comment into the top of every file. This did not make the team better at shipping something useful. Consistency is bullshit if it doesn't help you ship something that people care about.
    - cassianoleal 2y ago
      Shipping is not the end game. Things need to be operated and maintained, sometimes for many years to come. Consistency helps keep things more predictable and simpler to interpret and change.
  - gofreddygo 2y ago
    Yes. a cargo cult is devoid of questioning and critical thinking. It probably works for someone who came up with a practice that they don't want questioned or being held up to reason. Other than that, it's always bad.
leptons 2y ago
Today's "best practices" are tomorrow's "worst practices". I've seen it over and over in the 40+ years I've been writing software. Someone tells you "this is how you need to code", and then 1 or 2 years later, someone else tells you "that's trash, now code like this". Rinse and repeat.
- chipdart 2y ago
  The hard part is telling apart the tradeoffs of the new "code like this" claims, which often time are shit that fails to even consider the problems fixed by tlthe "old and busted". I mean, how come software development is the only field where everything done by your predecessors are shit?
- gofreddygo 2y ago
  Its pseudo-science and extends way beyond software in various parts of our life. Look at nutrition with a new superfood each year (pomegranate, seaweed, chia seeds, coconut oil, turmeric, ...) a new diet every couple years (keto, paleo, etc) Did the superfood of 2018 suddenly stop having all the antioxidants "benefits" ? Or did the hype cycle burn out?
  - gadflyinyoureye 2y ago
    To the foods, hype cycle burned out, but nutrition moved on. In the last few years it’s become apparent that that antioxidants needed to be balanced. Too many are just as bad as too few.
preommr 2y ago
> This was a revelation to me and got me thinking: what is OOP actually trying to solve? This is the problem in a nutshell. Someone comes up with sensible advice, and like a bad game of telephone it gets stripped down to some brain-dead phrase that gets parroted around by reflex. And it's everywhere in software. It was always things like "prefer composition over inheritance when possible" - people chose to ignore it, and go ham with sprawling inheritance trees and design patterns for different languages because of a superficial understanding of software because we optimize for all the wrong things. There's interview questions where they'll ask what are the four pillars of oop or some nonesense, and one of them will be inheritance or something and so if you're not doing it that way, it's bad practice.
5350-uiop-1130 2y ago
when i started my career, being a lazy dev was seen as a positive trope. it was understood as someone who is pragmatic in their choices. we all spoke the same language. now say you are lazy and your "resume" will get immediately trashed. different culture and people.
- reverius42 2y ago
  The Three Virtues according to Larry Wall: laziness, impatience, and hubris. https://thethreevirtues.com https://thethreevirtues.com
JohnMakin 2y ago
OOP is a blight upon our industry that I can't wait until people eventually figure out. Sorry, I know this is a hot take, and that it can be useful (one of my first primary languages was Java), but its potential for misuse and sprawling, spaghetti'd codebases is far too dangerous. I remember the first time I took a high-level programming theory course and ran into procedural languages and to that point I'd genuinely not even considered that another paradigm existed, I'd had OOP rammed down my throat in the form of C++/Java for 3 years straight.
- gadflyinyoureye 2y ago
  What do you think will replace it? Go is pulling back to procedural. I haven’t seen functional really take off. I don’t know Rust’s paradigm.
  - JohnMakin 2y ago
    Bash. Pure bash. /s Honestly, I don't know. I rarely find a need for it in my projects, but I'm more of a systems engineer than an application developer.
- nomel 2y ago
  Human thought processes determine programming language syntax, because that's why it exists. Encapsulation of context is a requirement for human understanding. OOP is just a trivial way to encapsulate, and represent that encapsulation. You can get rid of OOP, but the user interface/syntax for whatever will end up being mostly indistinguishable from OOP. I would claim that the bigger problem is people try to encapsulate things that shouldn't be.
  - JohnMakin 2y ago
    C has been cruisin along just fine without all that for a long time
    - nomel 2y ago
      Zoom out a bit. C can trivially handle OOP concepts [1]. Any complex code base will end up with functions that look no different than object methods, with the first argument being the equivalent of self, and class names found at the beginning of the function names MyObjectEquivelant_someMethod(MyInstanceEquivalent *pointer, ...). Here's a popular one: strlen(instance). [1] http://staff.washington.edu/gmobus/Academics/TCES202/Moodle/OO-ProgrammingInC.html http://staff.washington.edu/gmobus/Academics/TCES202/Moodle/...
PUSH_AX 2y ago
I agree with the takeaways here. Juniors, intermediates and more seniors than should, have a complete inability to zoom out and appreciate where their software fits in to the business. Hyper focused on minutia. Eager to debate in a PR. Once I learned how to zoom out I found it really difficult to work with a large number of engineers. I feel like I’m really overdue to step out of a hands on role nowadays.
- nomel 2y ago
  > inability to zoom out and appreciate where their software fits in to the business. Hyper focused on minutia. I would claim that the ability to not do these is what defines a senior.
- nine_zeros 2y ago
  Some of the best engineers are the ones not nitpicking on PRs. They are able to discern that the vast majority of issues are not worth nitpicking on.
mrkeen 2y ago
> In the OOP world I would have expected to see a Loan class with methods like create, get_offers, and make_payment. Rookie mistake! I'm usually very critical of OO, but this ain't it. Good OO is about delegation of behaviour. The Loan is not the payer, so no make_payment() method please. Same with create and get_offers (unless we're just talking about constructors/getters here, but I don't think that was the intent). If a Loan did have a make_payment, and get_offers: why stop there? It's also going to need calculate_interest(), persist_in_db(), renegotiate(), compare(), calculate_amortisation(), get_currency(), get_minimum_repayment(), forgive(), calculate_late_fee(), alert_late_customer(), and a hundred others to be figured out along the way. So it's good OO for a Loan to just be struct-ish (There's even a dumb word for it - "POJO"). Or, even better, just a UUID! You can apply some SOLID cargo-culting to the above. If you put so much behaviour into Loan, you'll be forever changing it, updating it, and risking unrelated breakages, violating the Single-responsibility principle ("one reason for a class to change"). I'm not a huge fan of that particular principle (it's vague and doesn't tell you how to fix it!) but I am a fan of Dependency Inversion (which does!). A Loan is abstract, we both know what we're describing - even though we have completely different tech stacks. If a Loan has get_offers(), those offers will need to come from somewhere, whether you're talking about other classes (OfferService? DiscountService?) or over http or via a database or something. And those are concrete (Java! JSON! Rest Calls! DB Tables!) DI says to flip the design around so that the concrete things instead know about the abstract Loan, and the Loan becomes sufficiently dumb. Then when it comes time to change interest calculations, you change only the InterestService, likewise with CurrencyConversionService, OfferService, etc. You're back to single responsibilites! > It turns out the command structure checks all of these boxes. It's dead simple to understand. There's no layer of indirection trying to piece together OOP hierarchies. It encapsulates the business logic developers actually want to run in a single place, you don't have to figure out how to wire together a bunch of objects on your own. And testing is dead simple, it's just a function with easy to understand inputs and outputs. If you skip the indirection and just test all your logic in a single place, you're bound to be tripped up by your dependencies. You can probably test 80% of `calculate_interest.rb` with just inputs, functions and outputs, but `make_loan_payment.rb`? There's going to be dependencies that you shouldn't invoke in a test scenario. The indirection & wiring is how you organise the code so that you can put test-doubles in the right places, and control exactly what you want to test for.
Const-me 2y ago
I agree with most of that article, but the answer to the question in the title is “it depends on the practices”. Some of software engineering best practices are universally applicable, and they really matter. Using version control for source code. Writing functional specs in some form (at least very high level in half page of text) before writing code. Using meaningful names for variables instead of a, b, c, d. Commenting the source code when necessary. The part I disagree is about the OOP. It’s not the best to write software, but very often the best way to design software which has to deal with complicated mutable state. FinTech system running on servers probably doesn’t need mutable state much or at all: things are immutable, transactions are appended to append-only ledgers, and the mutable state is only present in external systems like SQL databases. However, it’s borderline impossible to make a videogame, rich text editor, a file system, GUI framework, or an XML DOM without some form of OOP.
satisfice 2y ago
There are no best practices. “Best practices” is a marketing phrase, not an engineering one. There are practices I like. There are practices YOU like. There are practices that are demonstrably good in certain ways for certain situations. Instead of best practices, seek responsible practice. Develop your heuristics. Try things and learn your craft.

31 points by jshchnz 3y ago

I think this is a complicated issue. While I think it’s important to maintain focus on the actual point of software (delivering something useful to people), it’s important to not completely ignore the shoulders of the giants who came before us, to avoid learning old lessons the hardest, and avoid solving already solved problems. I think Tesla is guilty of this when it comes to their manufacturing. Elon wants to do everything from first principles to remove waste, meanwhile the “old guys” designed and rolled out competitive products to mass production, while Tesla struggled for years. Experience matters, but doesn’t mean anything if the playbook keeps getting thrown out.

philipov 2y ago
It's because rather than understanding that waste is eliminated through decades of practice optimizing a single process, Musk thinks it's eliminated by getting rid of stupid people who prioritize useless things like safety. It's a teenager's perspective on what's wrong with the world, "Why don't they just do it better?"

greymalik 2y ago

> The best practices we followed often felt like cargo cult programming. Best practices are cargo culting if they aren't adapted to the local context.

eddd-ddde 2y ago
Also, is cargo cult really that bad if it helps us stick with consistency?
- TehShrike 2y ago
  "consistency" isn't beneficial unless it makes you better at shipping something useful
  - bluefirebrand 2y ago
    I struggle to think of any time when consistency would not make you better at shipping something useful A codebase with consistent styles and patterns is easier to work on than a chaotic codebase, it would definitely make you better at shipping And so on
    - eddd-ddde 2y ago
      This was my line of thinking when making the comment. Obviously there has to be some balance, but in general I'm a fan of consistency, even if I'm not a big fan of the things we are being consistent on.
      - bluefirebrand 2y ago
        I think the problem with cargo culting isn't usually the stuff the cargo cult preaches It's the constant churn of dropping the current thing for the new cargo cult whenever it comes along. Cargo culting destroys consistency by constantly seeking the next new hotness
    - dolni 2y ago
      What if everything were written in C? Or Python? Or Java? We'd have massive consistency across the software industry and yet that would be an absolutely terrible idea.
    - TehShrike 2y ago
      I've seen codebases that were consistent in e.g. copy/pasting a meaningless comment into the top of every file. This did not make the team better at shipping something useful. Consistency is bullshit if it doesn't help you ship something that people care about.
  - cassianoleal 2y ago
    Shipping is not the end game. Things need to be operated and maintained, sometimes for many years to come. Consistency helps keep things more predictable and simpler to interpret and change.
- gofreddygo 2y ago
  Yes. a cargo cult is devoid of questioning and critical thinking. It probably works for someone who came up with a practice that they don't want questioned or being held up to reason. Other than that, it's always bad.

leptons 2y ago

Today's "best practices" are tomorrow's "worst practices". I've seen it over and over in the 40+ years I've been writing software. Someone tells you "this is how you need to code", and then 1 or 2 years later, someone else tells you "that's trash, now code like this". Rinse and repeat.

chipdart 2y ago
The hard part is telling apart the tradeoffs of the new "code like this" claims, which often time are shit that fails to even consider the problems fixed by tlthe "old and busted". I mean, how come software development is the only field where everything done by your predecessors are shit?
gofreddygo 2y ago
Its pseudo-science and extends way beyond software in various parts of our life. Look at nutrition with a new superfood each year (pomegranate, seaweed, chia seeds, coconut oil, turmeric, ...) a new diet every couple years (keto, paleo, etc) Did the superfood of 2018 suddenly stop having all the antioxidants "benefits" ? Or did the hype cycle burn out?
- gadflyinyoureye 2y ago
  To the foods, hype cycle burned out, but nutrition moved on. In the last few years it’s become apparent that that antioxidants needed to be balanced. Too many are just as bad as too few.

preommr 2y ago

> This was a revelation to me and got me thinking: what is OOP actually trying to solve? This is the problem in a nutshell. Someone comes up with sensible advice, and like a bad game of telephone it gets stripped down to some brain-dead phrase that gets parroted around by reflex. And it's everywhere in software. It was always things like "prefer composition over inheritance when possible" - people chose to ignore it, and go ham with sprawling inheritance trees and design patterns for different languages because of a superficial understanding of software because we optimize for all the wrong things. There's interview questions where they'll ask what are the four pillars of oop or some nonesense, and one of them will be inheritance or something and so if you're not doing it that way, it's bad practice.

5350-uiop-1130 2y ago

when i started my career, being a lazy dev was seen as a positive trope. it was understood as someone who is pragmatic in their choices. we all spoke the same language. now say you are lazy and your "resume" will get immediately trashed. different culture and people.

reverius42 2y ago
The Three Virtues according to Larry Wall: laziness, impatience, and hubris. https://thethreevirtues.com https://thethreevirtues.com

JohnMakin 2y ago

OOP is a blight upon our industry that I can't wait until people eventually figure out. Sorry, I know this is a hot take, and that it can be useful (one of my first primary languages was Java), but its potential for misuse and sprawling, spaghetti'd codebases is far too dangerous. I remember the first time I took a high-level programming theory course and ran into procedural languages and to that point I'd genuinely not even considered that another paradigm existed, I'd had OOP rammed down my throat in the form of C++/Java for 3 years straight.

gadflyinyoureye 2y ago
What do you think will replace it? Go is pulling back to procedural. I haven’t seen functional really take off. I don’t know Rust’s paradigm.
- JohnMakin 2y ago
  Bash. Pure bash. /s Honestly, I don't know. I rarely find a need for it in my projects, but I'm more of a systems engineer than an application developer.
nomel 2y ago
Human thought processes determine programming language syntax, because that's why it exists. Encapsulation of context is a requirement for human understanding. OOP is just a trivial way to encapsulate, and represent that encapsulation. You can get rid of OOP, but the user interface/syntax for whatever will end up being mostly indistinguishable from OOP. I would claim that the bigger problem is people try to encapsulate things that shouldn't be.
- JohnMakin 2y ago
  C has been cruisin along just fine without all that for a long time
  - nomel 2y ago
    Zoom out a bit. C can trivially handle OOP concepts [1]. Any complex code base will end up with functions that look no different than object methods, with the first argument being the equivalent of self, and class names found at the beginning of the function names MyObjectEquivelant_someMethod(MyInstanceEquivalent *pointer, ...). Here's a popular one: strlen(instance). [1] http://staff.washington.edu/gmobus/Academics/TCES202/Moodle/OO-ProgrammingInC.html http://staff.washington.edu/gmobus/Academics/TCES202/Moodle/...

PUSH_AX 2y ago

I agree with the takeaways here. Juniors, intermediates and more seniors than should, have a complete inability to zoom out and appreciate where their software fits in to the business. Hyper focused on minutia. Eager to debate in a PR. Once I learned how to zoom out I found it really difficult to work with a large number of engineers. I feel like I’m really overdue to step out of a hands on role nowadays.

nomel 2y ago
> inability to zoom out and appreciate where their software fits in to the business. Hyper focused on minutia. I would claim that the ability to not do these is what defines a senior.
nine_zeros 2y ago
Some of the best engineers are the ones not nitpicking on PRs. They are able to discern that the vast majority of issues are not worth nitpicking on.

mrkeen 2y ago

> In the OOP world I would have expected to see a Loan class with methods like create, get_offers, and make_payment. Rookie mistake! I'm usually very critical of OO, but this ain't it. Good OO is about delegation of behaviour. The Loan is not the payer, so no make_payment() method please. Same with create and get_offers (unless we're just talking about constructors/getters here, but I don't think that was the intent). If a Loan did have a make_payment, and get_offers: why stop there? It's also going to need calculate_interest(), persist_in_db(), renegotiate(), compare(), calculate_amortisation(), get_currency(), get_minimum_repayment(), forgive(), calculate_late_fee(), alert_late_customer(), and a hundred others to be figured out along the way. So it's good OO for a Loan to just be struct-ish (There's even a dumb word for it - "POJO"). Or, even better, just a UUID! You can apply some SOLID cargo-culting to the above. If you put so much behaviour into Loan, you'll be forever changing it, updating it, and risking unrelated breakages, violating the Single-responsibility principle ("one reason for a class to change"). I'm not a huge fan of that particular principle (it's vague and doesn't tell you how to fix it!) but I am a fan of Dependency Inversion (which does!). A Loan is abstract, we both know what we're describing - even though we have completely different tech stacks. If a Loan has get_offers(), those offers will need to come from somewhere, whether you're talking about other classes (OfferService? DiscountService?) or over http or via a database or something. And those are concrete (Java! JSON! Rest Calls! DB Tables!) DI says to flip the design around so that the concrete things instead know about the abstract Loan, and the Loan becomes sufficiently dumb. Then when it comes time to change interest calculations, you change only the InterestService, likewise with CurrencyConversionService, OfferService, etc. You're back to single responsibilites! > It turns out the command structure checks all of these boxes. It's dead simple to understand. There's no layer of indirection trying to piece together OOP hierarchies. It encapsulates the business logic developers actually want to run in a single place, you don't have to figure out how to wire together a bunch of objects on your own. And testing is dead simple, it's just a function with easy to understand inputs and outputs. If you skip the indirection and just test all your logic in a single place, you're bound to be tripped up by your dependencies. You can probably test 80% of `calculate_interest.rb` with just inputs, functions and outputs, but `make_loan_payment.rb`? There's going to be dependencies that you shouldn't invoke in a test scenario. The indirection & wiring is how you organise the code so that you can put test-doubles in the right places, and control exactly what you want to test for.

Const-me 2y ago

I agree with most of that article, but the answer to the question in the title is “it depends on the practices”. Some of software engineering best practices are universally applicable, and they really matter. Using version control for source code. Writing functional specs in some form (at least very high level in half page of text) before writing code. Using meaningful names for variables instead of a, b, c, d. Commenting the source code when necessary. The part I disagree is about the OOP. It’s not the best to write software, but very often the best way to design software which has to deal with complicated mutable state. FinTech system running on servers probably doesn’t need mutable state much or at all: things are immutable, transactions are appended to append-only ledgers, and the mutable state is only present in external systems like SQL databases. However, it’s borderline impossible to make a videogame, rich text editor, a file system, GUI framework, or an XML DOM without some form of OOP.

satisfice 2y ago

There are no best practices. “Best practices” is a marketing phrase, not an engineering one. There are practices I like. There are practices YOU like. There are practices that are demonstrably good in certain ways for certain situations. Instead of best practices, seek responsible practice. Develop your heuristics. Try things and learn your craft.