unclebobmartin

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.

You should be baffled, because I never presented that as a hard and fast rule.

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.

Ah, yes. The famous Sudoku solver controversy.

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.

That same year Peter Norvig wrote a Sudoku solver in Python using a constraint based approach. You can see their respective documents here. https://ronjeffries.com/categories/sudoku/… https://norvig.com/sudoku.html

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.

Yet another dunker. Oh well.

Muahahahaha!

Well, that's not the _only_ reason. ;-)

:-)

Who does that? Who uses guard rails like that? Accountants.

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.

Type systems do not force programmers to be disciplined. Type systems tempt programmers to cheat.

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.

That was cool!

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.

I use that style, from time to time, because I like it. ;-)

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.

I don't know Mr. Newton's beef. I found the virulence of his posts rather surprising since they were entirely off topic, and an attempt to make the topic about me, personally, rather than about what I wrote. Perhaps he will clarify.

Nimi, to be clear, I did not define agile; I simply collaborated in the effort that defined it.

In one post Robin2 described the course as OO, in another he described it as "C++". Those are two different courses so I'm not sure which it really was. However, back in those days we always did a brief lecture on TDD, as well as several other disciplines such as pairing, refactoring, etc. I was not at the class in question so I cannot comment on precisely what happened; but in general we tried to cover the bases of the various agile disciplines as part of any class we taught. Our customers knew this, and understood the implications. Object Mentor was, after all, the first and foremost of the Agile Transition companies. So all our courses had that flavor.

One last point. People like Donald Knuth and Brian Kernighan are heroes of mine. I would not sully their names by comparing them with the likes of me.

Does anybody here think that healthcare.gov was put together by experts? Or was it more likely a horde of novices?

I would vote for associations and guilds. I'm not a fan of licensing. I don't think we know enough to license people.

Nimi, the agile manifesto does not say "People and Interactions _instead_ of processes and tools". Indeed, the preamble to the manifesto is quite specific that we think processes and tools are good things. It's just that people and interactions should take precedence.

In light of that, your contention that teaching TDD is "very far from the principles of being agile" is somewhat misguided. Quite to the contrary, to disregard processes and tools is what would be far from agile.

My mistake. This was just another one of your misreported facts. The bio line on my blog says that I am an über _geek_; not an über _hacker_. And with _that_ characterization I must agree.

Live long and prosper.

Mr. Newton. Why is that the question? What does who I am have to do with what I wrote?

Now, if you'd like to know who I am, I'll be glad to tell you. I've been writing code since 1970. I started on PDP/8s and PDP/11s. I have written BAL, COBOL, Fortran, PL/1, C, C++, Java, C#, Ruby, Python, Clojure, and a bunch of other language I can't remember. I spent many years writing embedded software in 8080 assembler, to control telecommunications micr-controllers. I spent a year and a half working at Rational with Grady Booch on the first two releases of Rose (for my sins). I have written five books on software development and have edited two more. I called the meeting that founded the Agile movement, and served as the first chairman of the Agile Alliance. I was the editor-in-chief of the C++ Report for three years. I am the creator of cleancoders.com, which offers software development video training. Nowadays I spend my time speaking, teaching, making videos, writing blogs, and writing Clojure and Java code.

Is there anything else you'd like to know?

(BTW, the term "uber-hacker" is not mine, and is incorrect. I shall endeavor to get that removed.)

At the time of that course, Micah was supporting a very large C++ application, and had been for some years. Were his skills rusty? I rather doubt it.

In any case, --- what does this have to do with the article in the title line? It seems odd to be talking about something my son did nearly a decade ago in response to an article I wrote today?

Dear Mr Newton. My memory of the Cambridge event a few years back is rather different from what you report. As I recall, the room was packed, the reception was enthusiastic, as was the applause; and the folks who talked with me later were excited and congratulatory. I don't know who you talked to, but -- perhaps it's best not to report on things that you didn't attend.

As for Micah, my son, he runs a very successful software development company of 60 or so developers who specialize in extremely high quality software. He maintains very high standards for the developers who work for him. Every one of them practices TDD as well as many other practices that we've found to be beneficial. The result has been a steady stream of very satisfied customers and repeat business. Those customers would likely disagree with you about the reliability of his code; and the code of his employees. But then, I don't imagine your comment was based on any actual knowledge of his code. Perhaps it's best not to report on things you haven't seen.