u/unclebob

Agile is not a synonym for "without forethought". We like to think about the problem. We don't like thinking for months without writing code.

Just a note. Ron Jeffries, the author of the Sudoku articles, has likely forgotten more about CS than many of the rest of us ever learned. The point of that article was an experiment to see if the sudoku algorithm self assembled like so many do. (See The Transformation Priority Premise).

My response from 2006 still applies with one exception. FitNesse is now 70,000 lines of code, not 30,000. http://butunclebob.com/ArticleS.UncleBob.AgilePeopleStillDontGetIt

If your managers decide to ship code that you have not been able to test, for one reason or another, you should get them to sign a waiver that protects you from any liability. This is similar to having a patient sign an AMA waiver before leaving against medical advice.

Yes, it's true that sometimes the decision to ship is made despite that fact that the developers haven't been able to test. But that doesn't mean that DEVELOPERS should make that decision. Developers are only ready to ship once they know the system works.

It also seems to me that developers should be moving heaven and Earth to find a way to test the things that "Aren't Testable Until You Ship".

There is a minimum set of disciplines that qualify one as a software professional. A set of simple rules.

• A professional writes unit tests that achieve close to 100% code coverage. Those tests become part of the documentation for the software, and will always pass.

• A professional never releases messy code, because s/he knows that quick and dirty is an oxymoron. Professionals always create the cleanest code and the best design they can.

• A professional never checks in code that breaks any previously passing tests. If their code breaks a previously passing test, they fix it, regardless of where the break is.

• A professional knows that the deadline is not an excuse for sloppiness, and that the only way to reliably make deadlines is to be deliberate, disciplined, and clean.

There are probably more.

Comments Welcome.

Long ago I needed to calculate the area of an arbitrary polygon. This was before Google, so thumbed through my algorithm books and didn't find anything useful. So I stumbled around with a rough idea that you could subdivide the polygon into a set of triangles and then add up all their areas.

I got this algorithm working; but found it had O(N**3) behavior. This was bad news because the polygons I had to process were property lines that had hundreds of vertexes. The calculations were taking 45 min or more!

I had no idea how to continue. So I shelved the thing and moved on.

Months later I was reading a book on Prolog. There, in the middle of the book, was an algorithm for calculating the area of an arbitrary polygon. Better still, it had linear complexity. Better still, it was foolishly simple. (A line integral (duh)).

The moral of the story is: "You don't know what you don't know." This was before TDD of course, but I could have easily TDDd by way through that triangle algorithm, and would not have discovered the Line Integral solution.

Read books on algorithms. The more you know, the better. There are some great books on Queueing Theory, Geometrics, Graphs, etc. Sedgwick might be a good place to start; after Knuth of course.

There are lots of ways to describe TDD. One of them is:

Hypothesis/Experiment. You state an hypothesis in a test case. The hypothesis is not the assertion in the test case, it is your conjecture about the kind of code required to pass the test. The experiment comes in when you actually write the code that makes the test pass, and you compare that code to your conjecture. In some sense you are exploring the domain of possible solutions through empiricism.

This is not always efficient. You can reach local minima, and completely miss the underlying abstraction. On the other hand, it's a powerful tool for exploring the solution domain.

Good programmers use all the tools they can find. TDD is one such tool, and it is remarkably useful. But thinking about the design is also a powerful tool. The two are not mutually exclusive.

Hay psykotic, nice to meet you.

Now, about this "complete fraud" thing. Would you care to be more specific?

BTW, I learned TDD from Kent one happy afternoon while visiting him at his home. Then we drove up to see Crater Lake with his Kids. Ward and I have also paired on some TDD problems. Ward likes to goof around with assembly language in DSPs to generate video signals and stuff.