8 ms·

My problem with Uncle Bob's opinions is that they are pretty common within the industry, even if "discipline" really isn't the issue and all those negative feel

My problem with Uncle Bob's opinions is that they are pretty common within the industry, even if "discipline" really isn't the issue and all those negative feelings people allude to are warranted. In general, people are made to feel guilty for not being able to use the shitty tools and techniques we are given. Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors related to ORMs / Hibernate, because of an actual mismatch between relational data and object graphs, but then developers are made to feel guilty because they "aren't using it right", made to think that only if they switch this setting on, use this and that annotation, read a book or two, everything will be alright going forward. Most such projects fail from a technical perspective of course, because the developers having invested so much time in those shitty techniques, exploration of alternatives becomes unfathomable to them, because all of that effort which can span years ends up being unjustified. And I suspect that Uncle Bob is guilty as well. Lets take TDD as another example. I remember a time when TDD was religious dogma, which was unbelievable, because I couldn't see actual TDD in projects of companies advertising TDD in job descriptions. Much like Agile, Scrum and all that crap, it usually doesn't work because, as the masters will quickly tell you, you're "not doing it right". I've seen a single project where TDD was implemented by the book, but the developers where wasting so much time on testing stuff, including endless discussions, that they were forgetting TDD wasn't the actual artifact they had to deliver. Now Uncle Bob tells me that we don't have the discipline required. That's not surprising. I’ve been hearing this argument in some form or another for years. The surprise is the attention that we are paying to what Uncle Bob has to say.

martincmartin 9y ago
I assume you've seen "Object-Relational Mapping is the Vietnam of Computer Science"? http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...
- bitexploder 9y ago
  ORM is like C++. SQLAlchemy is the best ORM I know of. You can use it lightly and map tables, migrations, and never go deep into the ORM "problem". Saves you a lot of effort doing SQL push-ups. Many projects doing OO end up building a worse ORM from scratch eventually.
  - humanrebar 9y ago
    > Many projects doing OO end up building a worse ORM from scratch eventually. Sure, and lots of people end up implementing a lisp in C++. Doesn't necessarily mean they should just use a lisp instead. Usually it just means they should learn how to use their tools idiomatically.
201709User 9y ago
Bob makes money selling TDD to chumps.
vkuruthers 9y ago
I agree with this comment. OTOH it's very hard to have and enforce discipline in commercial SW development in the US anyway. Managers just want solutions hacked out as quick as possible, so no real time for properly crafting solutions in most cases. Scrum etc. also drives this type of mindset.
- walshemj 9y ago
  Agreed Scrum RAD DSDM are not suitable for all software projects.
thomascgalvin 9y ago
> Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors related to ORMs / Hibernate ... My teams don't use ORMs anymore. I've found that all of the time we "save" by not hand-writing SQL is instead lost fighting with the ORM, and problems with SQL are a lot easier to Google. I've also found that the ability to swap databases quickly is almost totally unimportant. 100% of the time we're targeting SQLite and PostgreSQL. I don't need a few extra thousand lines of code so I can theoretically support SQL Server running on a toaster in some kid's dorm somewhere.
- gyani95 9y ago
  How do you make sure that what you are writing is secure?
  - efdee 9y ago
    What difference does an ORM make?
    - zaphar 9y ago
      ORM's by and large do protect your from SQL injection attacks.
      - Sacho 9y ago
        By using prepared statements, which you can use as well.
      - nnq 9y ago
        They don't. All decent ORMs have a layers architecture, and it's usually some "query builder/processor" or "DAL" or whatever that sits under/above the ORM your app uses (and can usually also be used directly, but has a horrible API since it's not optimized for this use case) that does the simple but tricky tasks of parameter sanitization and all... The ORM is just an big fat thing that sits on top, and from which you only use 10% of the functionality it provides, but in theory each app uses a different 10% so it justifies itself... ORMs can be ok... as long as you don't build business logic on top of and inseparable from it! (As an example of horrible use of ORMs: some frameworks have ORM systems with an events system on top... god have mercy on your soul if you make the mistake of using this system to implement business logic, and end up with it accidentally depending on db connection and caching details, and not having time to refactor when you realize this! ...but if you avoid the trap, you can reap the benefits of the functionality that the ORM provides, while moving your logic at at a whole different layer of the app - hint: just invent a new "XBizLogicServices layer" or whatever and not import framework stuff into it if you can't find a better design, it will at least be easily testable.)
_wc0m 9y ago
Completely agree with this. The post where Martin derides modern, type-safe languages (Kotlin and Swift) [0] was just unbelievable to me. "Ask yourself why we are trying to plug defects with language features. The answer ought to be obvious. We are trying to plug these defects because these defects happen too often. Now, ask yourself why these defects happen too often. If your answer is that our languages don’t prevent them, then I strongly suggest that you quit your job and never think about being a programmer again; because defects are never the fault of our languages. Defects are the fault of programmers. It is programmers who create defects – not languages." Arrgh! Until we get out of this ridiculous, macho, victim-blaming mindset, software development will be stuck in the relative dark ages. More, better, safer languages, please! [0] http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath....
- oblio 9y ago
  Somebody should show Uncle Bob this: https://youtu.be/fPF4fBGNK0U https://youtu.be/fPF4fBGNK0U My point being: yes, if we'd be perfect drivers at all times and in all weather conditions there would be no more accidents. Luckily for us auto designers haven't adopted this perspective :)
  - msla 9y ago
    You just reminded me of my old driving instructor. "All accidents are your fault. Got rear-ended? Shouldn't have been driving so slowly, or shouldn't have stopped. Got t-boned? Should have looked more closely at the intersection. Skidded on ice? Shouldn't have been driving so quickly, or turned so sharply. Yes, you avoided the pedestrian, but that isn't an excuse. In extremis, you shouldn't have been driving that day at all, and you do always have that option, so it's your fault regardless." The line between empowerment and victim blaming is surprisingly thin. ;)
  - blktiger 9y ago
    This is a video of a crash _test_. Personally, I'm not sure TDD is necessarily the answer but even with typed code you should still have tests. You just don't need tests for things covered by the type system. Of course, it also depends on what the software is being used for. If I create a script for automating something just for me, I don't see any reason to add repeatable tests.
mannykannot 9y ago
Martin has built up a large following of acolytes, some of whom are very active wherever software development is discussed, in a very dogmatic way (such as the guys for whom TDD is the one true solution to every problem.) He has encouraged this through his didactic style of writing, which focuses on a few of the most basic faults in current development practice, and elevates them to being the roots of all evil, without any regard to the problems that you will run into once you have these surmounted.
- atulatul 9y ago
  Agree with this. I like some of his ideas. But a problem I have(possibly of my perception) with uncle Bob is that he gets too aggressive. If you don't have X percent (100%) code coverage, then you are doing it wrong, you are not a craftsman, etc. Well, Dan North put things in perspective a bit- https://dannorth.net/2011/01/11/programming-is-not-a-craft/ https://dannorth.net/2011/01/11/programming-is-not-a-craft/ The problem is dogma. And it keeps repeating. But probably this aggression helps them in their careers. (Not a frequent contributor to comments/ here on HN. Mostly like to read.)
  - unclebobmartin 9y ago
    I have never told people that they must have 100% test coverage. Indeed, I tell them that 100% test coverage is impossible. What you are referring to is a statement I frequently make -- 100% coverage is the goal. It's an asymptotic goal, but it's still the goal. No lesser goal makes any sense.
    - mannykannot 9y ago
      But then you can find people saying that type checking has no value because all errors will be caught by the testing you should be doing - I came across someone saying that just a few days ago. I am not sure that 100% can be called an asymptotic goal, given that you cannot even get close, for real systems. Once you recognize this, you can start having a realistic discussion about what you actually will be able to test for, how best to allocate your limited resources, and what other steps you might take to mitigate the consequences of this unfortunate fact. It means that methodologies bassed on extensive testing must justify this use. An additional benefit is that we might be able to discuss what we can do to improve software development without the sort of dogmatic non-sequitur that I mentioned in my first paragraph.
Chris2048 9y ago
The most common tactic for pushing TTD is confusing "no TDD" with "no testing". So many "benefits of TDD" begin with sabotaged examples of a team that doesn't test at all, before trying TDD - classic stone-soup.
arwhatever 9y ago
Someone help me with the origin of this (paraphrased) quote, which I have not been able to re-find on my own: "The sooner you admit that you can't fit the whole program's source code in your head, the sooner you can begin incorporating that into your design."
- Jtsummers 9y ago
  Notes on Structured Programming: http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF Page 3: Summarizing: as a slow-witted human being I have a very small head and I had better learn to live with it and to respect my limitations and give them full credit, rather than to try to ignore them, for the latter vain effort will be punished by failure. The Humble Programmer: http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF Page 11: The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. He expressed similar thoughts on other occasions. And there are others who express the same idea.
  - dorian-graph 9y ago
    Thank you for this! It's nice to have a large repository of EWD's writings.
s73ver_ 9y ago
I think you don't see much TDD in companies because, when a snag is hit, the first thing out the window is testing.
vkhorikov 9y ago
Do you need an ORM? http://enterprisecraftsmanship.com/2015/11/30/do-you-need-an-orm/ http://enterprisecraftsmanship.com/2015/11/30/do-you-need-an...
unclebobmartin 9y ago
There's nothing wrong with tools. I like tools. I use them all the time. I want better ones. I also want programmers to be able to use those tools well. Finally, I look at a lot of crap code written by programmers who throw all their disciplines away because of schedule pressure or other factors. For the sake of going fast they throw away everything that might allow them go actually go fast.

martincmartin 9y ago

I assume you've seen "Object-Relational Mapping is the Vietnam of Computer Science"? http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...

bitexploder 9y ago
ORM is like C++. SQLAlchemy is the best ORM I know of. You can use it lightly and map tables, migrations, and never go deep into the ORM "problem". Saves you a lot of effort doing SQL push-ups. Many projects doing OO end up building a worse ORM from scratch eventually.
- humanrebar 9y ago
  > Many projects doing OO end up building a worse ORM from scratch eventually. Sure, and lots of people end up implementing a lisp in C++. Doesn't necessarily mean they should just use a lisp instead. Usually it just means they should learn how to use their tools idiomatically.

201709User 9y ago

Bob makes money selling TDD to chumps.

vkuruthers 9y ago

I agree with this comment. OTOH it's very hard to have and enforce discipline in commercial SW development in the US anyway. Managers just want solutions hacked out as quick as possible, so no real time for properly crafting solutions in most cases. Scrum etc. also drives this type of mindset.

walshemj 9y ago
Agreed Scrum RAD DSDM are not suitable for all software projects.

thomascgalvin 9y ago

> Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors related to ORMs / Hibernate ... My teams don't use ORMs anymore. I've found that all of the time we "save" by not hand-writing SQL is instead lost fighting with the ORM, and problems with SQL are a lot easier to Google. I've also found that the ability to swap databases quickly is almost totally unimportant. 100% of the time we're targeting SQLite and PostgreSQL. I don't need a few extra thousand lines of code so I can theoretically support SQL Server running on a toaster in some kid's dorm somewhere.

gyani95 9y ago
How do you make sure that what you are writing is secure?
- efdee 9y ago
  What difference does an ORM make?
  - zaphar 9y ago
    ORM's by and large do protect your from SQL injection attacks.
    - Sacho 9y ago
      By using prepared statements, which you can use as well.
    - nnq 9y ago
      They don't. All decent ORMs have a layers architecture, and it's usually some "query builder/processor" or "DAL" or whatever that sits under/above the ORM your app uses (and can usually also be used directly, but has a horrible API since it's not optimized for this use case) that does the simple but tricky tasks of parameter sanitization and all... The ORM is just an big fat thing that sits on top, and from which you only use 10% of the functionality it provides, but in theory each app uses a different 10% so it justifies itself... ORMs can be ok... as long as you don't build business logic on top of and inseparable from it! (As an example of horrible use of ORMs: some frameworks have ORM systems with an events system on top... god have mercy on your soul if you make the mistake of using this system to implement business logic, and end up with it accidentally depending on db connection and caching details, and not having time to refactor when you realize this! ...but if you avoid the trap, you can reap the benefits of the functionality that the ORM provides, while moving your logic at at a whole different layer of the app - hint: just invent a new "XBizLogicServices layer" or whatever and not import framework stuff into it if you can't find a better design, it will at least be easily testable.)

_wc0m 9y ago

Completely agree with this. The post where Martin derides modern, type-safe languages (Kotlin and Swift) [0] was just unbelievable to me. "Ask yourself why we are trying to plug defects with language features. The answer ought to be obvious. We are trying to plug these defects because these defects happen too often. Now, ask yourself why these defects happen too often. If your answer is that our languages don’t prevent them, then I strongly suggest that you quit your job and never think about being a programmer again; because defects are never the fault of our languages. Defects are the fault of programmers. It is programmers who create defects – not languages." Arrgh! Until we get out of this ridiculous, macho, victim-blaming mindset, software development will be stuck in the relative dark ages. More, better, safer languages, please! [0] http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath....

oblio 9y ago
Somebody should show Uncle Bob this: https://youtu.be/fPF4fBGNK0U https://youtu.be/fPF4fBGNK0U My point being: yes, if we'd be perfect drivers at all times and in all weather conditions there would be no more accidents. Luckily for us auto designers haven't adopted this perspective :)
- msla 9y ago
  You just reminded me of my old driving instructor. "All accidents are your fault. Got rear-ended? Shouldn't have been driving so slowly, or shouldn't have stopped. Got t-boned? Should have looked more closely at the intersection. Skidded on ice? Shouldn't have been driving so quickly, or turned so sharply. Yes, you avoided the pedestrian, but that isn't an excuse. In extremis, you shouldn't have been driving that day at all, and you do always have that option, so it's your fault regardless." The line between empowerment and victim blaming is surprisingly thin. ;)
- blktiger 9y ago
  This is a video of a crash _test_. Personally, I'm not sure TDD is necessarily the answer but even with typed code you should still have tests. You just don't need tests for things covered by the type system. Of course, it also depends on what the software is being used for. If I create a script for automating something just for me, I don't see any reason to add repeatable tests.

mannykannot 9y ago

Martin has built up a large following of acolytes, some of whom are very active wherever software development is discussed, in a very dogmatic way (such as the guys for whom TDD is the one true solution to every problem.) He has encouraged this through his didactic style of writing, which focuses on a few of the most basic faults in current development practice, and elevates them to being the roots of all evil, without any regard to the problems that you will run into once you have these surmounted.

atulatul 9y ago
Agree with this. I like some of his ideas. But a problem I have(possibly of my perception) with uncle Bob is that he gets too aggressive. If you don't have X percent (100%) code coverage, then you are doing it wrong, you are not a craftsman, etc. Well, Dan North put things in perspective a bit- https://dannorth.net/2011/01/11/programming-is-not-a-craft/ https://dannorth.net/2011/01/11/programming-is-not-a-craft/ The problem is dogma. And it keeps repeating. But probably this aggression helps them in their careers. (Not a frequent contributor to comments/ here on HN. Mostly like to read.)
- unclebobmartin 9y ago
  I have never told people that they must have 100% test coverage. Indeed, I tell them that 100% test coverage is impossible. What you are referring to is a statement I frequently make -- 100% coverage is the goal. It's an asymptotic goal, but it's still the goal. No lesser goal makes any sense.
  - mannykannot 9y ago
    But then you can find people saying that type checking has no value because all errors will be caught by the testing you should be doing - I came across someone saying that just a few days ago. I am not sure that 100% can be called an asymptotic goal, given that you cannot even get close, for real systems. Once you recognize this, you can start having a realistic discussion about what you actually will be able to test for, how best to allocate your limited resources, and what other steps you might take to mitigate the consequences of this unfortunate fact. It means that methodologies bassed on extensive testing must justify this use. An additional benefit is that we might be able to discuss what we can do to improve software development without the sort of dogmatic non-sequitur that I mentioned in my first paragraph.

Chris2048 9y ago

The most common tactic for pushing TTD is confusing "no TDD" with "no testing". So many "benefits of TDD" begin with sabotaged examples of a team that doesn't test at all, before trying TDD - classic stone-soup.

arwhatever 9y ago

Someone help me with the origin of this (paraphrased) quote, which I have not been able to re-find on my own: "The sooner you admit that you can't fit the whole program's source code in your head, the sooner you can begin incorporating that into your design."

Jtsummers 9y ago
Notes on Structured Programming: http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF Page 3: Summarizing: as a slow-witted human being I have a very small head and I had better learn to live with it and to respect my limitations and give them full credit, rather than to try to ignore them, for the latter vain effort will be punished by failure. The Humble Programmer: http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF Page 11: The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. He expressed similar thoughts on other occasions. And there are others who express the same idea.
- dorian-graph 9y ago
  Thank you for this! It's nice to have a large repository of EWD's writings.

s73ver_ 9y ago

I think you don't see much TDD in companies because, when a snag is hit, the first thing out the window is testing.

vkhorikov 9y ago

Do you need an ORM? http://enterprisecraftsmanship.com/2015/11/30/do-you-need-an-orm/ http://enterprisecraftsmanship.com/2015/11/30/do-you-need-an...

unclebobmartin 9y ago

There's nothing wrong with tools. I like tools. I use them all the time. I want better ones. I also want programmers to be able to use those tools well. Finally, I look at a lot of crap code written by programmers who throw all their disciplines away because of schedule pressure or other factors. For the sake of going fast they throw away everything that might allow them go actually go fast.