5 ms·

> Bob Martin saying "The solution to the software apocalypse is not more tools. The solution is better programming discipline." A lot of Robert C Martins piece

by bedobi 5y ago

> Bob Martin saying "The solution to the software apocalypse is not more tools. The solution is better programming discipline." A lot of Robert C Martins pieces are just variations on his strong belief that ill-defined concepts like "craftsmanship" and "clean code" (which are basically just whatever his opinions are on any given day) is how to reduce defects and increase quality, not built-in safety and better tools, and if you think built-in safety and better tools are desirable, you're not a Real Programmer (tm). I'm not the only one who is skeptical of this toxic, holier-than-thou and dangerous attitude. Removing braces from if statements is a great example of another dangerous thing he advocates for no justifiable reason https://softwareengineering.stackexchange.com/questions/320247/has-can-anyone-challenge-uncle-bob-on-his-love-of-removing-useless-braces/320262 https://softwareengineering.stackexchange.com/questions/3202... Which caused the big OSX/iOS SSL bug in 2014, see https://www.imperialviolet.org/2014/02/22/applebug.html https://www.imperialviolet.org/2014/02/22/applebug.html This link and thread on hackernews is good too https://news.ycombinator.com/item?id=15440848 https://news.ycombinator.com/item?id=15440848 The current state of software safety discussion resembles the state of medical safety discussion 2, 3 decades ago (yeah, software is really really behind time). Back then, too, the thoughts on medical safety also were divided into 2 schools: the professionalism and the process oriented. The former school argues more or less what Uncle Bob argues: blame the damned and * who made the mistakes; be more careful, damn it. But of course, that stupidity fell out of favor. After all, when mistakes kill, people are serious about it. After a while, serious people realize that blaming and clamoring for care backfires big time. That's when they applied, you know, science and statistic to safety. So, tools are upgraded: better color coded medicine boxes, for example, or checklists in surgery. But it's more. They figured out what trainings and processes provide high impacts and do them rigorously. Nurses are taught (I am not kidding you) how to question doctors when weird things happen; identity verification (ever notice why nurses ask your birthday like a thousand times a day?) got extremely serious; etc. My take: give it a few more years, and software, too, probably will follow the same path. We needs more data, though.

mirekrusin 5y ago
Linter or compiler should warn/error on unreachable code in this example, shouldn't it?
- bedobi 5y ago
  Not according to Uncle Bob
deleted 5y ago
[deleted]
throwawaythekey 5y ago
It's not really fair to call craftsmanship toxic. The obvious local maximum is to embrace craftsmanship on a personal level and profit from the tooling of others (preferably outside of your own company). Wait... maybe that is toxic.
- AlotOfReading 5y ago
  There's nothing wrong with craftsmanship and it can coexist happily with what's described in the GP. Most of the engineering marvels of the early 20th century were done with an abundance of incredibly skilled craftsman running machine tools and process controls. The toxicity is in blaming an inherently fallible human for having the audacity to be fallible. It's not productive, it's just an intellectual dead end.
  - bedobi 5y ago
    This. Everyone, even the best, most experienced people, can and do slip and make outright mistakes. If someone's answer to that is "just don't slip or make mistakes", well... I don't even know what to say to that, it's so dumb it can't really be meaningfully responded to.
    - tharkun__ 5y ago
      It's the combination of things if you ask me. I'm out of car analogies today but how about a software analogy? "just don't slip or make mistakes" makes sense as an "Acceptance Criteria". The implementation details of that? I minimize my mistakes and slip ups by doing things like always fully curly-bracing all of my if-statements and actually enforcing it through a linter that doesn't let me merge any code to master that doesn't adhere to this rule, because it'll make the build red and our repo doesn't allow me to merge anything that doesn't have a green build and I can't push directly to master. Do I still slip up sometimes? Sure, the build catches it. The slip ups this doesn't catch? We try to find implementation details that reduce those slip ups too. Rinse, repeat. If you slip up as a manager/team lead? Show your developers. Show how you handle it. Lead by example.
    - 5y ago
jerf 5y ago
One of the things I love about software is that if you put your mind to it, you can have some of both. You can have both the culture and the process, because with software, we can create cultures of encoding process into automated procedures, like continuous integration and strong automated testing suites. This obviously doesn't completely solve the "culture or process?" question on its own. I just enjoy software for having a relatively unusual place where the two can be overlapped. I'd have a hard time going into any other engineering field where I lost unit tests, they're so integrated into how I think. I actually kinda consider myself personally not all that strong with processes... but you wouldn't know it to look at my output because I put the processes in my code. (This is also one of the reasons I find the slowly-but-not-slowly-enough dwindling obsession with claiming programming isn't a "real engineering discipline" to be silly. We don't do what all the other engineers do because we have quite a lot of options that are better than what other engineers do. Sure, if you're a "senior" dev who has never heard of a unit test, you may be cowboying it too much, but, I mean, other engineering disciplines would murder for some of the processes we can create around quality.)
zz865 5y ago
Yeah I like his book in general, but all the gurus usually work on their own or dip into projects. I'd love to see him in a typical code base that was written by a bunch of people that left years ago and a manager that wants new functionality tomorrow.

by bedobi 5y ago

mirekrusin 5y ago

Linter or compiler should warn/error on unreachable code in this example, shouldn't it?

bedobi 5y ago
Not according to Uncle Bob

deleted 5y ago

[deleted]

throwawaythekey 5y ago

It's not really fair to call craftsmanship toxic. The obvious local maximum is to embrace craftsmanship on a personal level and profit from the tooling of others (preferably outside of your own company). Wait... maybe that is toxic.

AlotOfReading 5y ago
There's nothing wrong with craftsmanship and it can coexist happily with what's described in the GP. Most of the engineering marvels of the early 20th century were done with an abundance of incredibly skilled craftsman running machine tools and process controls. The toxicity is in blaming an inherently fallible human for having the audacity to be fallible. It's not productive, it's just an intellectual dead end.
- bedobi 5y ago
  This. Everyone, even the best, most experienced people, can and do slip and make outright mistakes. If someone's answer to that is "just don't slip or make mistakes", well... I don't even know what to say to that, it's so dumb it can't really be meaningfully responded to.
  - tharkun__ 5y ago
    It's the combination of things if you ask me. I'm out of car analogies today but how about a software analogy? "just don't slip or make mistakes" makes sense as an "Acceptance Criteria". The implementation details of that? I minimize my mistakes and slip ups by doing things like always fully curly-bracing all of my if-statements and actually enforcing it through a linter that doesn't let me merge any code to master that doesn't adhere to this rule, because it'll make the build red and our repo doesn't allow me to merge anything that doesn't have a green build and I can't push directly to master. Do I still slip up sometimes? Sure, the build catches it. The slip ups this doesn't catch? We try to find implementation details that reduce those slip ups too. Rinse, repeat. If you slip up as a manager/team lead? Show your developers. Show how you handle it. Lead by example.
  - 5y ago

jerf 5y ago

One of the things I love about software is that if you put your mind to it, you can have some of both. You can have both the culture and the process, because with software, we can create cultures of encoding process into automated procedures, like continuous integration and strong automated testing suites. This obviously doesn't completely solve the "culture or process?" question on its own. I just enjoy software for having a relatively unusual place where the two can be overlapped. I'd have a hard time going into any other engineering field where I lost unit tests, they're so integrated into how I think. I actually kinda consider myself personally not all that strong with processes... but you wouldn't know it to look at my output because I put the processes in my code. (This is also one of the reasons I find the slowly-but-not-slowly-enough dwindling obsession with claiming programming isn't a "real engineering discipline" to be silly. We don't do what all the other engineers do because we have quite a lot of options that are better than what other engineers do. Sure, if you're a "senior" dev who has never heard of a unit test, you may be cowboying it too much, but, I mean, other engineering disciplines would murder for some of the processes we can create around quality.)

zz865 5y ago

Yeah I like his book in general, but all the gurus usually work on their own or dip into projects. I'd love to see him in a typical code base that was written by a bunch of people that left years ago and a manager that wants new functionality tomorrow.