5 ms·

Uncle Bob has great advice that a large swath of the industry can benefit from. Keep in mind that a large portion of the industry, especially in corporate Ameri

Uncle Bob has great advice that a large swath of the industry can benefit from. Keep in mind that a large portion of the industry, especially in corporate America, writes really bad code and his advice helps these people to put guardrails around that. The 10% bad advice I would attribute to the 10% of instances when "the rules" should be broken. But the key to breaking the rules is having an understanding of why the rules are there and as such why they should be broken. His dogmatic approach is partially, from what I've seen, a counterbalance to the sloppiness that a large part of the industry, especially corporate America, has with software development. Can you take it too far and create beautiful software that does not solve any problems? Sure, but on the flip side it is also easy to create a lot of technical debt. With things like TDD, when devs are new to it, part of the learning process is to take it too far first and then as you understand it you learn the right balance.

xorcist 4y ago
TDD has been around for two decades now. One would expect there to be some high profile success story. Yet none of the important software projects we use on a day to day basis seems to utilize it. Not even one.
- lgleason 4y ago
  I'm not sure what tech stacks you work on, but I've worked with lots of tech stacks and high profile projects that use it and also saw the quality that resulted from the practice.
- jacquesm 4y ago
  The whole idea that something has to have a high profile success story available to the public for it to be an actual success doesn't really hold. Lots of people are far more busy with their work than they are with blogging and/or publicity. There are plenty of examples in my practice of quiet successes, some using TDD, some without and for those companies it may well have been a factor. Depending on the industry, reliability and ability to ship software that functions as advertised from day #1 can be a huge advantage, and for others it can be a wash or even a competitive disadvantage if it consumes too many resources. But I would not dismiss any such tool out of hand just because you personally have not seen or heard about the success stories.
  - lgleason 4y ago
    agreed
  - xorcist 4y ago
    Oh, absolutely. It's the lack of quiet successes that is notable here. Like Linux, or apt, or nginx, or Python, or at least a popular Python module. Or anything, really. After two decades of consulting in the software industry, you belong to a certain professional network. People love to talk, even if they won't always name their customers. I know people using formal methods and verification, in niches of the industry really, but have no indication that TDD is utilized for any big flagship products where it really matters. I'm sure there are a few highly blogged about industry stories somewhere, but there's a world of a difference between those and a long time success in software development as a whole. There were high profile books written about Rational Unified Process, for example, and ~ nobody uses that anymore.
- guhidalg 4y ago
  Wrong? https://github.com/linux-test-project/ltp/wiki https://github.com/linux-test-project/ltp/wiki https://github.com/neovim/neovim/tree/master/test https://github.com/neovim/neovim/tree/master/test https://github.com/openssl/openssl/blob/master/test/README.ssltest.md https://github.com/openssl/openssl/blob/master/test/README.s... What are you trying to say, that people don't write tests for their code?
  - chrisoverzero 4y ago
    Are you trying to say that “Test-Driven Development” is “writ[ing] tests for their code”? Test-Driven Development means that the tests are written before the features.
    - jdlshore 4y ago
      That's a common misunderstanding, but it's not true. TDD involves writing the tests at the same time as the code in tiny little steps. Write a few lines of test code that fail --> write a few lines of production code to make it pass --> refactor if needed to clean things up --> repeat.
      - chrisoverzero 4y ago
        > Write a few lines of test code that fail OK, write the test… > write a few lines of production code to make it pass …before the feature. I recognize the color you’re trying to add (it’s more like TFTFTF than TTTFFF), but it remains Test-Driven Development.
        jdlshore 4y ago
        Sure, if you insist. I've seen enough people misunderstand TDD to be TTTFFF that I think it's important to clarify.
  - lgleason 4y ago
    I would agree with this, but perhaps the commenter has a different definition of "high profile" ¯\_(ツ)_/¯
- marginalia_nu 4y ago
  I've sort of half-suspected that TDD doesn't actually exist. I've never met anyone who does it. I've seen people talk it up a lot, and programming shops sometimes claim to be all about TDD, but when you look at how they work it's not TDD at all, but some token unit tests after the development is finished.
  - oriolid 4y ago
    I have met one. His excuse for pushing broken code to trunk was "but it passes the unit tests". The same person also managed to write unit tests with >90% line coverage that just didn't check any results.
- 4140tm 4y ago
  How do you know what testing/designing practices all "important" software projects use? Do you expect it to be advertised?
  - xorcist 4y ago
    It's been twenty years. People would have moved on to new jobs, and spread the word with them. Some would have applied for jobs there. After all, non-googlers know a thing or two about their infrastructure, despite being mostly a trade secret. If nothing else, apparently there are enough of disciples out there that it would be a great way of hiring the right people. You'd have to believe there is some sort of cabal, completely bent on keeping this enormous advantage to themselves in absolute secrecy, to argue that it is a software development success story.
layer8 4y ago
Uncle Bob gives some very bad advice. For example, he advocates passing temporary state between methods implicitly in instance variables instead of explicitly (and nonshared) via arguments and return values, increasing the statefulness of the code and creating complex ordering constraints and preconditions for method invocations. E.g. https://softwareengineering.stackexchange.com/questions/288712/clean-code-can-private-methods-rely-on-member-variables-set-by-other-private-me https://softwareengineering.stackexchange.com/questions/2887... One can’t recommend his books with good conscience to anyone who doesn’t already have a very good judgment regarding software design and can pick out the parts that actually make sense.
- eurasiantiger 4y ago
  Uncle Bob sees classes as animals with internal state, not as abstract structures grouping together consumable APIs and their internal workings. Calling bound functions ”methods” is perhaps a bit misleading.

xorcist 4y ago

TDD has been around for two decades now. One would expect there to be some high profile success story. Yet none of the important software projects we use on a day to day basis seems to utilize it. Not even one.

lgleason 4y ago
I'm not sure what tech stacks you work on, but I've worked with lots of tech stacks and high profile projects that use it and also saw the quality that resulted from the practice.
jacquesm 4y ago
The whole idea that something has to have a high profile success story available to the public for it to be an actual success doesn't really hold. Lots of people are far more busy with their work than they are with blogging and/or publicity. There are plenty of examples in my practice of quiet successes, some using TDD, some without and for those companies it may well have been a factor. Depending on the industry, reliability and ability to ship software that functions as advertised from day #1 can be a huge advantage, and for others it can be a wash or even a competitive disadvantage if it consumes too many resources. But I would not dismiss any such tool out of hand just because you personally have not seen or heard about the success stories.
- lgleason 4y ago
  agreed
- xorcist 4y ago
  Oh, absolutely. It's the lack of quiet successes that is notable here. Like Linux, or apt, or nginx, or Python, or at least a popular Python module. Or anything, really. After two decades of consulting in the software industry, you belong to a certain professional network. People love to talk, even if they won't always name their customers. I know people using formal methods and verification, in niches of the industry really, but have no indication that TDD is utilized for any big flagship products where it really matters. I'm sure there are a few highly blogged about industry stories somewhere, but there's a world of a difference between those and a long time success in software development as a whole. There were high profile books written about Rational Unified Process, for example, and ~ nobody uses that anymore.
guhidalg 4y ago
Wrong? https://github.com/linux-test-project/ltp/wiki https://github.com/linux-test-project/ltp/wiki https://github.com/neovim/neovim/tree/master/test https://github.com/neovim/neovim/tree/master/test https://github.com/openssl/openssl/blob/master/test/README.ssltest.md https://github.com/openssl/openssl/blob/master/test/README.s... What are you trying to say, that people don't write tests for their code?
- chrisoverzero 4y ago
  Are you trying to say that “Test-Driven Development” is “writ[ing] tests for their code”? Test-Driven Development means that the tests are written before the features.
  - jdlshore 4y ago
    That's a common misunderstanding, but it's not true. TDD involves writing the tests at the same time as the code in tiny little steps. Write a few lines of test code that fail --> write a few lines of production code to make it pass --> refactor if needed to clean things up --> repeat.
    - chrisoverzero 4y ago
      > Write a few lines of test code that fail OK, write the test… > write a few lines of production code to make it pass …before the feature. I recognize the color you’re trying to add (it’s more like TFTFTF than TTTFFF), but it remains Test-Driven Development.
      - jdlshore 4y ago
        Sure, if you insist. I've seen enough people misunderstand TDD to be TTTFFF that I think it's important to clarify.
- lgleason 4y ago
  I would agree with this, but perhaps the commenter has a different definition of "high profile" ¯\_(ツ)_/¯
marginalia_nu 4y ago
I've sort of half-suspected that TDD doesn't actually exist. I've never met anyone who does it. I've seen people talk it up a lot, and programming shops sometimes claim to be all about TDD, but when you look at how they work it's not TDD at all, but some token unit tests after the development is finished.
- oriolid 4y ago
  I have met one. His excuse for pushing broken code to trunk was "but it passes the unit tests". The same person also managed to write unit tests with >90% line coverage that just didn't check any results.
4140tm 4y ago
How do you know what testing/designing practices all "important" software projects use? Do you expect it to be advertised?
- xorcist 4y ago
  It's been twenty years. People would have moved on to new jobs, and spread the word with them. Some would have applied for jobs there. After all, non-googlers know a thing or two about their infrastructure, despite being mostly a trade secret. If nothing else, apparently there are enough of disciples out there that it would be a great way of hiring the right people. You'd have to believe there is some sort of cabal, completely bent on keeping this enormous advantage to themselves in absolute secrecy, to argue that it is a software development success story.

layer8 4y ago

Uncle Bob gives some very bad advice. For example, he advocates passing temporary state between methods implicitly in instance variables instead of explicitly (and nonshared) via arguments and return values, increasing the statefulness of the code and creating complex ordering constraints and preconditions for method invocations. E.g. https://softwareengineering.stackexchange.com/questions/288712/clean-code-can-private-methods-rely-on-member-variables-set-by-other-private-me https://softwareengineering.stackexchange.com/questions/2887... One can’t recommend his books with good conscience to anyone who doesn’t already have a very good judgment regarding software design and can pick out the parts that actually make sense.

eurasiantiger 4y ago
Uncle Bob sees classes as animals with internal state, not as abstract structures grouping together consumable APIs and their internal workings. Calling bound functions ”methods” is perhaps a bit misleading.