Is Uncle Bob serious?
dev.to
Is Uncle Bob serious?
1–10 of 181 posts
Re: Is Uncle Bob serious?
#2I am in favour of high standards in software, but Mr Martin always seems to come up short of specific measures to get there. He does not much beyond the "man up and show some personal responsibility" school of discipline.
This doesn't seem to me to be the right way to get there. I would prefer approaches that are driven by data, experiment and outcomes - i.e. what works. I would expect that ideas such as "blameless postmortems" after failures, which are inevitable; and encouraging openness and team safety would have a better outcome than this clenched "just don't fuck up" stuff.
https://www.inc.com/leigh-buchanan/most-productive-teams-at-...
Re: Is Uncle Bob serious?
#3I talked with a few mechanical engineers, a much older profession than software engineering. They have higher standards and whatnot, but I'm seriously happy that I don't work in that industry. Many I talked to even switched to SE because it's easier money and people in SE are more relaxed.
Re: Is Uncle Bob serious?
#4uncle bob wrote good things but some shitty personal advices. That said, Dijkstra formal style of development will never work because capitalism, that shit that you all from HN think it's great, leads to self destruction in engineering. but yeah. talk to me more shit abt how the fuck the invisible hand scoops your shit
Re: Is Uncle Bob serious?
#5It is my continued theory that Bob Martin is a double agent, whose mission is to discredit TDD in the wider software community by using an infuriating, backlash-inducing writing style.
Re: Is Uncle Bob serious?
#6I talked with a few mechanical engineers, a much older profession than software engineering. They have higher standards and whatnot, but I'm seriously happy that I don't work in that industry. Many I talked to even switched to SE because it's easier money and people in SE are more relaxed.
> They have higher standards and whatnot
Note that "higher standards" in civil engineering usually boils down to a) having standards at all instead of fuzzy process management frameworks b) these standards often boil down to "do this task/product with this regulatory mandated large margin of error" and c) building according to specification (i.e. having a reliable specification in the first place), which is exactly how reliable software is built (SIL, ASIL, aerospace level redundancy). There is nothing magical about it, but it needs to be driven by business and is not something that us lowly developers can just chose to do on a whim (because it increases costs by a factor 10 - 100).
Embracing agile (as his ThoughtWorks contract requires him to do) while lamenting quality and lack of professionalism, as Mr Martin does, is extremely dishonest.
Re: Is Uncle Bob serious?
#7The points made in the article linked here are interesting, but I now recommend anyone interested in improving the software industry simply steer clear of Bob Martin. Sometimes he says interesting or relevant things, but most of the time he just seems to be a professional troll these days. As far as I can tell he has a high profile but little relevant experience or qualification to make all these grand pronouncements or to justify insulting those of us who think other tools or techniques or processes might be better, so I suggest that for anyone interested in the field of high reliability software, time would be better spent studying books and papers written by people who have real experience and demonstrable results to support their arguments.
Re: Is Uncle Bob serious?
#8I talked with a few mechanical engineers, a much older profession than software engineering. They have higher standards and whatnot, but I'm seriously happy that I don't work in that industry. Many I talked to even switched to SE because it's easier money and people in SE are more relaxed.
> They have higher standards and whatnot Note that "higher standards" in civil engineering usually boils down to a) having standards at all instead of fuzzy process management frameworks b) these standards often boil down to "do this task/product with this regulatory mandated large margin of error" and c) building according to specification (i.e. having a reliable specification in the first place), which is exactly h…
> Embracing agile (as his ThoughtWorks contract requires him to do) while lamenting quality and lack of professionalism, as Mr Martin does, is extremely dishonest.
Why exactly? I fail to see the connection between lack of quality and embracing agile.
Re: Is Uncle Bob serious?
#9I talked with a few mechanical engineers, a much older profession than software engineering. They have higher standards and whatnot, but I'm seriously happy that I don't work in that industry. Many I talked to even switched to SE because it's easier money and people in SE are more relaxed.
> They have higher standards and whatnot Note that "higher standards" in civil engineering usually boils down to a) having standards at all instead of fuzzy process management frameworks b) these standards often boil down to "do this task/product with this regulatory mandated large margin of error" and c) building according to specification (i.e. having a reliable specification in the first place), which is exactly h…
Embracing agile (as his ThoughtWorks contract requires him to do) while lamenting quality and lack of professionalism, as Mr Martin does, is extremely dishonest.
"It is difficult to get a man to understand something when his salary depends upon his not understanding it." -- Upton Sinclair
Re: Is Uncle Bob serious?
#10Both better tools and better software discipline is needed.
Better tools could help a lot. It's hard to see how anyone disagrees with that. But, on the flip side, at my most pessimistic, I find that a massive % (say, 50%) of developers struggle to do the most basic things correctly. I can't fathom the types or scope of tools needed to solve the size of the problem (real AI that puts us all out of a job??).
So, while we wait for a thousand silver bullets, I agree with Uncle Bob: more automated tests, more pair programming, more code reviews. Whatever new tool they come up with, without basic competence, discipline and vigilance, things aren't going to change.