4 ms·

> not that actually formalizing them into a proper craftsmanship wouldn’t make sense if we actually made better best practices. This is the start of a bureaucr

> not that actually formalizing them into a proper craftsmanship wouldn’t make sense if we actually made better best practices. This is the start of a bureaucracy that will grind progress to a halt. Because now instead of solving problems we get to create a commission who can appoint a club that have the right to appoint the master craftsmen who will be capable enough to formalize best practices. If you think that's hyperbole on how this stuff works, it is not. Furthermore, why would we assume people who enjoy debating best practices know actual master craftsmen? > The fact that said standards may not yet exist is not an argument against that, it’s an argument against the status quo in standards. The fact that said standards have been tried, and you don't know about them is a very strong argument against them.

Apocryphon 5y ago
> This is the start of a bureaucracy that will grind progress to a halt. Because now instead of solving problems we get to create a commission who can appoint a club that have the right to appoint the master craftsmen who will be capable enough to formalize best practices. This bureaucracy already exists, across myriads of RFCs, language design committees, FOSS groups, GitHub issues, Gitter servers, listservs. This process already exists, it just bumbles along inconsistently from community to community, company to company, project to project. And perhaps it should, because no size fits all. But it does exist and any attempt at formalizing them would not cause the start of a bureaucracy to exist, because such bureaucracies are in abundance in software development already.
- native_samples 5y ago
  If you define a bureaucracy making best practices so broadly as to capture GitHub issues, then the term becomes meaningless. The sense the OP is trying to argue for (rather unsuccessfully) is a government bureaucracy that forbids people from deviating from those best practices. This is "serious", you see, whereas a competitive market of ideas leading to the organic development of best practices (what we have now) is "trivial". The problem with that idea is that although it pleases people who associate government control with seriousness, the evidence it actually leads to better outcomes is mixed at best, and negative at worst. Regulatory capture is a real problem in many industries, and the attempt to fix things with regulated "best practices" can often be short term hacks that also inconveniently render more robust long term fixes illegal (finance has a lot of problems like this). In the software world you can look at things like MISRA-C or FIPS to get a taste of what everything would look like if we don't keep systematically pushing back against these misguided people.
  - Apocryphon 5y ago
    I don’t think government control is necessary. Much of what the OP is talking about can be undertaken by industry standards, or just by enough software engineers and software firms agreeing upon it, whether through a body like an IEEE or unofficially like how Agile spread in popularity.
    - native_samples 5y ago
      We agree then! But the article author disagrees: "Software practitioners should be licensed and be bound by a professional ethical code where violation of said code would result in the revocation of the license to practice software engineering." The article very clearly argues for government control of who can be a programmer or not (who is doing the revoking, otherwise). That would be destructive, fatal to innovation and totally counterproductive.
      - Apocryphon 5y ago
        Sure, though this discussion doesn't have to be limited to the OP's constraints.

Apocryphon 5y ago

> This is the start of a bureaucracy that will grind progress to a halt. Because now instead of solving problems we get to create a commission who can appoint a club that have the right to appoint the master craftsmen who will be capable enough to formalize best practices. This bureaucracy already exists, across myriads of RFCs, language design committees, FOSS groups, GitHub issues, Gitter servers, listservs. This process already exists, it just bumbles along inconsistently from community to community, company to company, project to project. And perhaps it should, because no size fits all. But it does exist and any attempt at formalizing them would not cause the start of a bureaucracy to exist, because such bureaucracies are in abundance in software development already.

native_samples 5y ago
If you define a bureaucracy making best practices so broadly as to capture GitHub issues, then the term becomes meaningless. The sense the OP is trying to argue for (rather unsuccessfully) is a government bureaucracy that forbids people from deviating from those best practices. This is "serious", you see, whereas a competitive market of ideas leading to the organic development of best practices (what we have now) is "trivial". The problem with that idea is that although it pleases people who associate government control with seriousness, the evidence it actually leads to better outcomes is mixed at best, and negative at worst. Regulatory capture is a real problem in many industries, and the attempt to fix things with regulated "best practices" can often be short term hacks that also inconveniently render more robust long term fixes illegal (finance has a lot of problems like this). In the software world you can look at things like MISRA-C or FIPS to get a taste of what everything would look like if we don't keep systematically pushing back against these misguided people.
- Apocryphon 5y ago
  I don’t think government control is necessary. Much of what the OP is talking about can be undertaken by industry standards, or just by enough software engineers and software firms agreeing upon it, whether through a body like an IEEE or unofficially like how Agile spread in popularity.
  - native_samples 5y ago
    We agree then! But the article author disagrees: "Software practitioners should be licensed and be bound by a professional ethical code where violation of said code would result in the revocation of the license to practice software engineering." The article very clearly argues for government control of who can be a programmer or not (who is doing the revoking, otherwise). That would be destructive, fatal to innovation and totally counterproductive.
    - Apocryphon 5y ago
      Sure, though this discussion doesn't have to be limited to the OP's constraints.