I'm 72. As for what I have shipped over the half-century of my career, you can read all about that in part two of my book We, Programmers. Suffice it to say I've shipped a LOT of code.
Actually, I presented that figure as an example of just how difficult that problem was to understand, and how (on a bike ride) I was finally able to visualize what was going on. The ascii image was presented a bit tongue in cheek.
However, if you study that image, you might come to the same insight that I (on my bike ride) came to; and that the english comments never helped me with.
In 2006 Ron Jeffries wrote four blogs about solving Sudoku in Ruby with TDD. His blogging effort ended before he completed the solution. I think he got interested in something else and left the whole thing hanging.
The anti-TDD lobby, at the time, hailed the two documents as proof that TDD didn't work. Ha Ha, Nya Nya Boo Boo.
I was aware of this silliness, but never bothered to study it. I had better things to do. Until March of 2020. Then I thought I'd use Sudoku as a case study for Episode 62 in http://cleancoders.com.
I had not read either of the previous documents and decided to maintain that ignorance while writing the solver in Clojure using TDD. It turned out to be a rather trivial problem to solve. You can see my solution in http://github.com/unclebob/sudoku
I don't know why Ron stopped blogging his Sudoku solver in 2006; but he picked it up again in 2024 and has written much more about it.
The trick I used to solve Sudoku with TDD was to consider the degenerate cases. Sudoku is usually a 3x3x3x3 grid. Let's call this a rank-3 problem. I started with a rank 1 problem which is trivial to solve. Then I moved on to a rank 2 problem which was relatively simple to solve; but was also very close to a general solution. After that I could solve rank N problems.
The TDD strategy of starting with the most degenerate case (rank 1) and then gradually adding complexity may not have been well known in 2006. TDD was pretty new back then. If you explore Ron's first four blogs you can see that he briefly considered rank 2 but opted to go straight into the rank 3 case. The sheer number of variables for each test (81) may have played a role in his loss of interest. In my case (rank 2) I had far fewer variables to deal with.
It's the CEO's job to demand the impossible. It's the engineer's job to deal with reality. When the engineer tells the CEO that the impossible is possible, the engineer has forsaken his/her responsibilities.
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.
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.
Only if you design your tests that way. Tests are just software. If a change to one part of a software system requires massive changes to another part of that same system; then the system is poorly designed. Indeed, that may be the very definition of poor design.
So if a change to your production code causes large changes to your test code, then one, or the other, or both are poorly designed. You have neglected the design. You have allowed couplings to proliferate.
If you don't want to use TDD, then that's fine. But make sure that you are not doing TDD for the right reasons.
The reasons to not to TDD are:
1. You don't care about the quality of your product.
2. You don't care about the quality of your code.
3. You don't care if there are any bugs.
4. You don't care if the team slows down month after month.
5. You don't care if the project is late.
6. You don't care if the project fails.
If you _do_ care about any of these things; then you should be using a unit testing discipline that guarantees that every line of production code is covered, and checked, by automated unit tests.
Oh, and make sure you know what TDD is. TDD is NOT:
1. Writing all your tests before you write any code.
2. Slow.
3. Too Low level.
If you think TDD is one or more of the above, then you need to do some more research.
Honestly, the year is 2015, and people _still_ resist the one discipline that can actually make a project come in on time, with high quality, and good structure.
Just to be clear, the name "Uncle Bob" was given to me by a coworker in 1989. It was in my email and uunet signature for years. (There are kids out there who don't know what uunet was). The name stuck, and I eventually adopted it as a brand.
Not at all. SRP is about enhancing the cohesion of things that change for the same reasons, and decreasing the coupling between things that change for different reasons.
SRP is very simple. If two different people want to change a class for two different reasons, then pull those reasons into two different classes.
That is the SRP.
Example: A class that analyzes a data stream and prints a report. The data analysis will interest one group of people. The format of the report will interest another, different, group. The first group will ask for changes to the algorithms. The second will ask for changes to the format. The principle says to separate those two concerns.
This goes all the way back to David Parnas and the separation of concerns. His papers that describe it are freely available on the web. I suggest that they be studied, because they are full of wisdom and insight.