4 ms·

> Everybody seems to have an opinion on how you do your web dev and how websites and web apps should be structured. It’s true and it leads to many annoying unp

> Everybody seems to have an opinion on how you do your web dev and how websites and web apps should be structured. It’s true and it leads to many annoying unproductive arguments, IMO the reason is a fundamental lack of a scientific mindset in evaluating techniques and tooling. We don’t have theories or testable hypotheses, we have opinions. On one level I like and agree with the author’s idea that results are what really matter. As an engineer trying to achieve outcomes for employers, clients, and customers, this approach has served me well. As a community of professionals, it would be nice to see more effort to work towards rigorously proven conclusions about what works best and why. When someone touts a paradigm, technique, or framework as the best, without any real data or theory as to why, I think they should be told to provide evidence or withdraw their argument, and I’d say that goes double when it’s the framework or technique you like or use. IMO, these shouldn’t be fights about tech, they should be ones about quality of discourse.

deleted 4y ago
[deleted]
patrick451 4y ago
It's shocking to me how little data there seems to be to support what many consider to be "best practice". About the only real data point I see thrown around is that bugs per LOC being fairly constant. Thus, you get people saying long, two-page functions are bad and should be broken up. But never have I seen someone backup such an exhortation with data. Let alone more nebulous rules like "objects should be open for extension and closed for modification," or anything out SOLID, really.
- bcrosby95 4y ago
  Breaking up code can increase your LOC, so the remedy doesn't even follow the premise.
  - taeric 4y ago
    I really wish more folks understood that point.
- eastbound 4y ago
  In the olden times there were scientists actually researching project management, measuring, changing inputs, performing experiments, probably at IBM or NASA. We don’t do this anymore, because IT is now less costly, and sometimes doing the thing is faster than writing the plan for it. So Agile won. Probably deterministic methodologies got stuck in a local minimum, which was ridiculously expensive to run compared to Agile. I still have my book of IBM RUP process.
- berkes 4y ago
  It is there. E.g. The book Accelerate! by Forsgren et.al. explains, scientific, what methods and concepts produce better and worse software. In an accessible way. There are numerous papers on how TDD does X to your software or team. Numerous theses on how static typing causes more or less Y and so on. Yet here we are, ignoring all that and discussing the pro's and cons of TDD based on a YouTube video, a blogpost, an anecdote and mostly a giant pile of ego and opinions.
  - wizofaus 4y ago
    Do those papers all agree? And what's the right course of action if, for instance, everyone in your team hates using TDD and threatens to resign or switch teams if you attempt to enforce it? Though surely it's more likely that something like "TDD" isn't an either-or proposition, and even if the evidence clearly shows the effectiveness in particular scenarios or when done in a particular manner, its not a given that more TDD is always better, and hence there's still benefit to discussing the pros and cons.
    - berkes 4y ago
      Off course they don't agree. Though I have asked numerous times to come up with scientific research or arguments that prove the science in e.g. Accelerate! wrong, no-one, not even the strongest opponent of CI, TDD or such, ever has produced that. Instead, people come with handwavy nonharguments that "in this particular scenario it is different". To which I neither agree nor disagree. I only have proof that it does apply, even to scenario X. It's up to "you" to then, scientifically prove that it doesn't apply. Point being: again: we should have discussions about tabs, spaces, TDD, CI, lean, agile, microservices based on scientific research. In a scientific manner. Not based on anecdotes and personal feelings.
      - wizofaus 4y ago
        Sure, but unless someone's taken the time to do the studies, anecdotes are the best data we have. And I'm not entirely dismissive of personal feelings either, when they're formed as the result of years of experience exploring different techniques. Especially because I tend to feel there's more to software development than just "engineering", and there's a creative side to it that's never going to be completely reducible to whether technique A is measurably better than technique B. Certainly in a tech lead type role, being aware of how those in your team enjoy working individually while still sticking to basic principles and guidelines that allow the team as a whole to produce quality code in a timely fashion is one of hardest balancing acts to get right.
abc_lisper 4y ago
This is a wonderful comment! There is missing descriptions of things, the quality, the metrics to use when describing such things and we, the users of those said tools end up spending a lot of time going through bad documentation and learning things by practice. For a trade that pushes the digital frontier to everything it touches, the learning is surprisingly analog.
- prox 4y ago
  Read the book About Face : Essentials of Interaction Design, it’s a great resource on design and make projects around interaction as the title suggests.
belenos46 4y ago
I'm in complete agreement with you. At this point, I also endorse threats of flogging for someone who tries to introduce a new framework to a project after the actual work has started. And actual flogging for the management team if they accept that framework.
- porker 4y ago
  As a data point I've just joined a small project which already has a JS framework (Vue) and 2 build systems (1 broken) and the developer has just added React and a third build system. No talk of migration - they're going to run in parallel.
  - ratww 4y ago
    The migration is often also a source of problems in itself. There's nothing wrong with neither Vue or React, but adding a second one of those for no reason deserves the flogging thing that the grandparent poster is talking about. Build systems... well they're a dime a dozen and in Javascript all build tools kinda suck (yes, including Vite), but still no excuse for having two.
    - wizofaus 4y ago
      Curious why you suggest all JS build tools suck... previous company I was at had .NET, Java (backend), golang, iOS, Android and JS (react) builds, that all compiled, ran unit tests, packaged and deployed to relevant targets. The react build was the least problematic by far (though we did get bitten on upgrading the host OS which upgraded node to a version incompatible certain older packages being used, but it didn't take too long to fix). Accepted, there was probably a little less functionality in that component than the mobile apps , but iOS was far and away the most problematic, FWIW).
      - ratww 4y ago
        "Suck" doesn't mean "worse compared to others". It means it has problems by itself that I would prefer not having to deal with. Ideally we'd need no build tools for JS. Except for JSX, modern browsers are mature enough. Other languages build tools are often terrible too, the only one I actually enjoy is probably Cargo. As for the real answer: for trivial stuff, all build tools work fine. For anything beyond that they still have varying degrees of problems. You seem to have encountered those in iOS but not in the JS tool you used. An engineer working on a super vanilla iOS project but a complex JS project would probably say the opposite. Vite works quite well for most part, but there's still quite a lot that can go wrong with it. It depends on two other build tools (esbuild and Rollup), so some otherwise trivial configurations are difficult and prone to break with upgrades. But for happy-path stuff it works perfectly. Most of the time a vanilla configuration is fine, but sometimes you have special requirements (sometimes due to vendors or specific technologies) that the younger tools aren't good for, while older tools have their own issues.
taeric 4y ago
Sorta. It isn't a lack of a scientific mindset. I argue it is a premature quantification of data such that you can objectively look at it in a scientific way. We are taught that you can compare things objectively in most school level science classes. This leads folks to thinking their perspective is valid scientifically. Especially if they can put numbers to it. After all, isn't that native empiricism?
prox 4y ago
And still a lot of devs I have met haven’t read About Face : Essentials of Interaction Design. It’s a must read in my book to structure around a project. You don’t have to copy paste it’s ideas, but using its core features makes a project a whole lot smoother for both end user and devs.

deleted 4y ago

[deleted]

patrick451 4y ago

It's shocking to me how little data there seems to be to support what many consider to be "best practice". About the only real data point I see thrown around is that bugs per LOC being fairly constant. Thus, you get people saying long, two-page functions are bad and should be broken up. But never have I seen someone backup such an exhortation with data. Let alone more nebulous rules like "objects should be open for extension and closed for modification," or anything out SOLID, really.

bcrosby95 4y ago
Breaking up code can increase your LOC, so the remedy doesn't even follow the premise.
- taeric 4y ago
  I really wish more folks understood that point.
eastbound 4y ago
In the olden times there were scientists actually researching project management, measuring, changing inputs, performing experiments, probably at IBM or NASA. We don’t do this anymore, because IT is now less costly, and sometimes doing the thing is faster than writing the plan for it. So Agile won. Probably deterministic methodologies got stuck in a local minimum, which was ridiculously expensive to run compared to Agile. I still have my book of IBM RUP process.
berkes 4y ago
It is there. E.g. The book Accelerate! by Forsgren et.al. explains, scientific, what methods and concepts produce better and worse software. In an accessible way. There are numerous papers on how TDD does X to your software or team. Numerous theses on how static typing causes more or less Y and so on. Yet here we are, ignoring all that and discussing the pro's and cons of TDD based on a YouTube video, a blogpost, an anecdote and mostly a giant pile of ego and opinions.
- wizofaus 4y ago
  Do those papers all agree? And what's the right course of action if, for instance, everyone in your team hates using TDD and threatens to resign or switch teams if you attempt to enforce it? Though surely it's more likely that something like "TDD" isn't an either-or proposition, and even if the evidence clearly shows the effectiveness in particular scenarios or when done in a particular manner, its not a given that more TDD is always better, and hence there's still benefit to discussing the pros and cons.
  - berkes 4y ago
    Off course they don't agree. Though I have asked numerous times to come up with scientific research or arguments that prove the science in e.g. Accelerate! wrong, no-one, not even the strongest opponent of CI, TDD or such, ever has produced that. Instead, people come with handwavy nonharguments that "in this particular scenario it is different". To which I neither agree nor disagree. I only have proof that it does apply, even to scenario X. It's up to "you" to then, scientifically prove that it doesn't apply. Point being: again: we should have discussions about tabs, spaces, TDD, CI, lean, agile, microservices based on scientific research. In a scientific manner. Not based on anecdotes and personal feelings.
    - wizofaus 4y ago
      Sure, but unless someone's taken the time to do the studies, anecdotes are the best data we have. And I'm not entirely dismissive of personal feelings either, when they're formed as the result of years of experience exploring different techniques. Especially because I tend to feel there's more to software development than just "engineering", and there's a creative side to it that's never going to be completely reducible to whether technique A is measurably better than technique B. Certainly in a tech lead type role, being aware of how those in your team enjoy working individually while still sticking to basic principles and guidelines that allow the team as a whole to produce quality code in a timely fashion is one of hardest balancing acts to get right.

abc_lisper 4y ago

This is a wonderful comment! There is missing descriptions of things, the quality, the metrics to use when describing such things and we, the users of those said tools end up spending a lot of time going through bad documentation and learning things by practice. For a trade that pushes the digital frontier to everything it touches, the learning is surprisingly analog.

prox 4y ago
Read the book About Face : Essentials of Interaction Design, it’s a great resource on design and make projects around interaction as the title suggests.

belenos46 4y ago

I'm in complete agreement with you. At this point, I also endorse threats of flogging for someone who tries to introduce a new framework to a project after the actual work has started. And actual flogging for the management team if they accept that framework.

porker 4y ago
As a data point I've just joined a small project which already has a JS framework (Vue) and 2 build systems (1 broken) and the developer has just added React and a third build system. No talk of migration - they're going to run in parallel.
- ratww 4y ago
  The migration is often also a source of problems in itself. There's nothing wrong with neither Vue or React, but adding a second one of those for no reason deserves the flogging thing that the grandparent poster is talking about. Build systems... well they're a dime a dozen and in Javascript all build tools kinda suck (yes, including Vite), but still no excuse for having two.
  - wizofaus 4y ago
    Curious why you suggest all JS build tools suck... previous company I was at had .NET, Java (backend), golang, iOS, Android and JS (react) builds, that all compiled, ran unit tests, packaged and deployed to relevant targets. The react build was the least problematic by far (though we did get bitten on upgrading the host OS which upgraded node to a version incompatible certain older packages being used, but it didn't take too long to fix). Accepted, there was probably a little less functionality in that component than the mobile apps , but iOS was far and away the most problematic, FWIW).
    - ratww 4y ago
      "Suck" doesn't mean "worse compared to others". It means it has problems by itself that I would prefer not having to deal with. Ideally we'd need no build tools for JS. Except for JSX, modern browsers are mature enough. Other languages build tools are often terrible too, the only one I actually enjoy is probably Cargo. As for the real answer: for trivial stuff, all build tools work fine. For anything beyond that they still have varying degrees of problems. You seem to have encountered those in iOS but not in the JS tool you used. An engineer working on a super vanilla iOS project but a complex JS project would probably say the opposite. Vite works quite well for most part, but there's still quite a lot that can go wrong with it. It depends on two other build tools (esbuild and Rollup), so some otherwise trivial configurations are difficult and prone to break with upgrades. But for happy-path stuff it works perfectly. Most of the time a vanilla configuration is fine, but sometimes you have special requirements (sometimes due to vendors or specific technologies) that the younger tools aren't good for, while older tools have their own issues.

taeric 4y ago

Sorta. It isn't a lack of a scientific mindset. I argue it is a premature quantification of data such that you can objectively look at it in a scientific way. We are taught that you can compare things objectively in most school level science classes. This leads folks to thinking their perspective is valid scientifically. Especially if they can put numbers to it. After all, isn't that native empiricism?

prox 4y ago

And still a lot of devs I have met haven’t read About Face : Essentials of Interaction Design. It’s a must read in my book to structure around a project. You don’t have to copy paste it’s ideas, but using its core features makes a project a whole lot smoother for both end user and devs.