This is pushing the envelope of anti-intellectualism even by Go standards. I read this post and the post it referenced and in both cases I’ll be damned if I can divine any sort of argument being made aside from: “programmers are stupid”
It is an exercise in constructing a bad faith, strawman opponent to knock down. If your ideas are so good, test them against the best possible counterargument!
I couldn’t figure out what this article meant by “test last development”. Did it mean not writing tests at all, or did it mean writing the tests after writing the implementation?
I think the single most harmful thing about “TDD” culture is the way it implies that writing the tests before the implementation is the most important characteristic of good software development.
The quality of the software I wrote went up a great deal when I started allowing myself to write tests before, during and after the implementation phase without feeling guilty about not exclusively writing them before.
I think they are implying that you put tests last by priority. This implies in most jobs you will never actually get to do it, since by being the lowest priority, any new tasks you receive are always above it, like “resource starvation” in concurrent programming if threads have too low a priority value and a poorly designed scheduler is used.
I fully agree that too much impact is placed on when you write the tests, rather than that they get created at all.
I thought this article was going to be in dialog with the referred article, maybe expanding or critiquing it, but it literally copied many of the same subheadings verbatim, and a lot of the content is similar, just reworded.
Is this some SEO thing for backlinks and reputation?
I hate to be cynical, but the posts are extremely similar, and I’m not sure why bitfield submitted this one, instead of his own.
One of my students writes a blog post about software testing, citing an article by me. I share it here, and that’s somehow… suspicious?
I promise you Jakub is a real person (you can find many videos of him giving talks, for example) and has his own views on this stuff: some of them aligned with my own, some not. Many of my other students write blog posts, too, and I don’t apologise for sharing and boosting them where I think their work deserves a larger audience. If you don’t agree, don’t upvote them, but let’s give the ‘just asking questions’ routine a rest, shall we?
The suspicious part was how incredibly similar the articles were, down to structure, order, and including “literally copied many of the same subheadings verbatim”. It doesn’t look naturally written at all. It looks like if your student sat down with your post and retyped it, changing small bits as they went along.
If not for the unusually high similarity, I wouldn’t have batted an eyelash.
Ignoring the poor article, TDD is hard because what client is actually making customer tests?
This is even harder when considering novel (to the developer) domains and problems. How can you describe the problem and answer before even exploring the problem space? (This is where gradually typed languages like Common Lisp and Racket shine.)
There are many ways to divide up the field of software. One way is between tasks where “specification first” speeds things up, and tasks where that slows things down. Many systems- and infrastructure-level tasks are in the first bucket, and most UI, frontend, and crud tasks are in the latter bucket. Many things are also a mix of the two, with some places where specifications are known up-front, and some where they are discovered during development.
Most of the heat in the world of TDD (which is one flavor of specification first) comes from folks working on these two classes of problems talking past each other. This article seems like another example of that.
This is pushing the envelope of anti-intellectualism even by Go standards. I read this post and the post it referenced and in both cases I’ll be damned if I can divine any sort of argument being made aside from: “programmers are stupid”
It is an exercise in constructing a bad faith, strawman opponent to knock down. If your ideas are so good, test them against the best possible counterargument!
I couldn’t figure out what this article meant by “test last development”. Did it mean not writing tests at all, or did it mean writing the tests after writing the implementation?
I think the single most harmful thing about “TDD” culture is the way it implies that writing the tests before the implementation is the most important characteristic of good software development.
The quality of the software I wrote went up a great deal when I started allowing myself to write tests before, during and after the implementation phase without feeling guilty about not exclusively writing them before.
I think they are implying that you put tests last by priority. This implies in most jobs you will never actually get to do it, since by being the lowest priority, any new tasks you receive are always above it, like “resource starvation” in concurrent programming if threads have too low a priority value and a poorly designed scheduler is used.
I fully agree that too much impact is placed on when you write the tests, rather than that they get created at all.
I don’t get it, is it saying that test-first development is “so damn hard” because devs are lazy and stupid?
Not only that, but they also don’t practice, and they only ship to appease management. Stupid devs.
I’m a little confused about the purpose of this post.
It refers to another article by bitfield, who submitted it to Lobsters, and calls him his mentor.
I thought this article was going to be in dialog with the referred article, maybe expanding or critiquing it, but it literally copied many of the same subheadings verbatim, and a lot of the content is similar, just reworded.
Is this some SEO thing for backlinks and reputation?
I hate to be cynical, but the posts are extremely similar, and I’m not sure why bitfield submitted this one, instead of his own.
I think you need to connect some dots for us here.
One of my students writes a blog post about software testing, citing an article by me. I share it here, and that’s somehow… suspicious?
I promise you Jakub is a real person (you can find many videos of him giving talks, for example) and has his own views on this stuff: some of them aligned with my own, some not. Many of my other students write blog posts, too, and I don’t apologise for sharing and boosting them where I think their work deserves a larger audience. If you don’t agree, don’t upvote them, but let’s give the ‘just asking questions’ routine a rest, shall we?
The suspicious part was how incredibly similar the articles were, down to structure, order, and including “literally copied many of the same subheadings verbatim”. It doesn’t look naturally written at all. It looks like if your student sat down with your post and retyped it, changing small bits as they went along.
If not for the unusually high similarity, I wouldn’t have batted an eyelash.
To me it seemed a bit satirical, maybe, but I can’t be sure.
Ignoring the poor article, TDD is hard because what client is actually making customer tests?
This is even harder when considering novel (to the developer) domains and problems. How can you describe the problem and answer before even exploring the problem space? (This is where gradually typed languages like Common Lisp and Racket shine.)
There are many ways to divide up the field of software. One way is between tasks where “specification first” speeds things up, and tasks where that slows things down. Many systems- and infrastructure-level tasks are in the first bucket, and most UI, frontend, and crud tasks are in the latter bucket. Many things are also a mix of the two, with some places where specifications are known up-front, and some where they are discovered during development.
Most of the heat in the world of TDD (which is one flavor of specification first) comes from folks working on these two classes of problems talking past each other. This article seems like another example of that.