41–50 of 112 posts
It's all just noise. Theres nothing wrong with having your pet theory, I just wish entire industries wouldn't carelessly hop on board every time some consultant comes up with an acronym and some promises.
This is a really irksome way for me to work, and I find that level of diligence difficult to muster. Often I will find myself writing the production code first and writing tests to cover after the fact. My coverage is probably not as high as it is when I TDD the code.
The cadence of TDD'd projects I've worked on professionally is painfully slow and predictable. If you're at a workplace that is giving you the time and resources to do it, then you're likely also pairing, which helps impatient souls like me stick to the program. My team has been blessed to have a devops guy who has a scientific mind and acts as informal agile coach while pairing - and he's probably the reason we do a good job on the TDD because he makes us all better at it.
If you're at a workplace that is encouraging TDD and pairing, you should be thankful and honestly try to do a great job at it. Your work weeks will be relaxed and you probably won't need to work much overtime. I wind up with lots of left over energy to burn on my home projects, which I appreciate.
For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't. His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing! Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him t…
> As usual my advice on this is: look at the people who build things you find highly impressive, and study how they did it. This is much more fruitful than reading the output of people who want to spend all day telling you how to program (which leaves very little time for them to build software that is impressive, i.e. they never even test their own ideas!) "Uncle Bob" Martin has built a lot of impressive things. Mos…
I'm not an anti-TDD zealot, but I don't personally do it, nor require any of my developers to do it (but they can, if it helps them).
As with everything in software, some things work well for some people, and not so much for others.
Instead of TDD, HDD works best for me. https://www.youtube.com/watch?v=f84n5oFoZBc
For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't. His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing! Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him t…
TDD is better than no tests most of the time I think. So at least that's a gain altogether.
For example, at our shop, we don't require devs to do TDD, however we require test coverage.
I don't think anyone would argue that writing tests at all is a bad idea, I think the debate is whether or not your tests should drive your application code.
Tdd is actual engineering: requirements first, set expectations, plan, estimate, build. Silicon Valley (generalization) has extreme shortsghtedness when it comes to building software, there are a lot of prima donnas, hipsters using whatever is cool,tech decisions made on opinion rather than measurement, and NIH. Have a spine and push for tdd. The prima donnas will attack you ad hominum and call you slow. But it feels…
So, all the process that is known for decades to mostly not work for software?
Tdd is actual engineering: requirements first, set expectations, plan, estimate, build. Silicon Valley (generalization) has extreme shortsghtedness when it comes to building software, there are a lot of prima donnas, hipsters using whatever is cool,tech decisions made on opinion rather than measurement, and NIH. Have a spine and push for tdd. The prima donnas will attack you ad hominum and call you slow. But it feels…
Tdd is actual engineering: requirements first, set expectations, plan, estimate, build. Silicon Valley (generalization) has extreme shortsghtedness when it comes to building software, there are a lot of prima donnas, hipsters using whatever is cool,tech decisions made on opinion rather than measurement, and NIH. Have a spine and push for tdd. The prima donnas will attack you ad hominum and call you slow. But it feels…
That's why conservative engineering traditions mandate that whenever one sets out to design a bridge, the very first thing to do is to build a really heavy car.
Earlier quoted context omitted.
> As usual my advice on this is: look at the people who build things you find highly impressive, and study how they did it. This is much more fruitful than reading the output of people who want to spend all day telling you how to program (which leaves very little time for them to build software that is impressive, i.e. they never even test their own ideas!) "Uncle Bob" Martin has built a lot of impressive things. Mos…
I've been using FitNesse heavily at work for the past few years, and I've been surprised by how buggy we've found it. We have over 30,000 tests and we've had to rewrite part of it because it memory-leaked so badly. Unfortunately the company has strict rules against contributing back to Open Source projects.
Free but very buggy.
For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't. His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing! Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him t…
> But he doesn't. Because the benefits aren't higher, in fact they are lower I am genuinely curious, what do you mean with this claim? I mean, yes the costs are high [1], but when properly paid, do the benefits still end up smaller than without practicing TDD? Which concrete benefits we miss when doing TDD? Uncle Bob has stated many of benefits of TDD elsewhere and did not mention them in this post. Many of his publi…
I am talking about any scheme of how to do things that is intended to provide benefit. These all start with "wouldn't it be better if X, because Y" and then a plan is made of how to bring this about.
Well, this plan is inevitably imperfect, so it is either that you don't get all of X, or the reasons Y were not correctly understood or accounted for.
Then, there are always some extra drawbacks that creep in that negate some of the benefits. Usually these drawbacks are very subtle, and they can be hard to notice because they are not things that the plan was trying to address.
In the end, usually the net result is negative: the scheme causes more damage than it provides in benefit. But usually it takes a long time to understand this clearly, because the drawbacks can be subtle (but sometimes they aren't, for example, in TDD, how much extra code you are writing all the time).