I’m looking at your response in another window so I don’t forget the points I want to respond to.

First of all, as in almost all discussions I have had about TDD, you are not writing advocacy of TDD so much as of regression testing in general. Which I am all in favor of, but don’t want to do myself, partially for the blind spot reasons I mentioned and have written about, but also because I find testing to be mostly tedious and the peevishness I get from tedium breaks my concentration. Not as severely as a meeting, but I would rather others did the testing. Of course I confirm that it works as best I can before handing it over. Bugs in basic functionality are embarrassing.

The differences that TDD brings to regression testing in general are the two I object to:

  1. writing tests before code
  2. being the primary tester of my own code, which I think is wantonly irresponsible.

But I can’t be too strident about the latter because most of my 31 years of software development have been solo. I prefer ownership of entire components and prefer in group settings (I dislike “team,” it sounds like sports) to have very high levels of division; on my last gig I Owned all four servers, the database, IIS administration and communications with the service provider; one other developer did the browser work. I’ve always worked this way; before I had been a developer for three full years I had written and shipped two entire Microsoft products singlehandedly. One of them was the original version of the SQL Server Management Console, a far lesser application than the current one.
Even in these cases we had some test resources, sometimes untrained people who simply operate the software and look for things that don’t work.

You would have found that reintroduced bug through any kind of regression testing; it need not be unit tests.And it need not be a test that was written before the code.

Blackbox testing can be automated, it need not be repetitive manual testing (something I wouldn’t wish on anyone); all it means is that the person creating the tests works from a specification of expected behavior, not from knowledge of the code. The latter is whitebox testing and we traditionally regard this as strictly for preliminary testing before, as you say, throwing it over the wall to QA.

Another thing I didn’t mention. To make code testable often means compromising the design; I’ve read of people who change a method from private to public to be able to call it in a unit test. I argue that all code-level testing should be for public entrypoints only.

I don’t claim TDD is without value; I don’t know if you read my linked articles but I spent a lot of time at Microsoft where a lot of procedures I regarded as important like threat modeling in cryptographic programming were treated as just a box to check, and I actually got in trouble for being too thorough. In my introduction to TDD and unit testing this was right out in the open; they didn’t care about the validity of the tests at all, they just wanted to check the box.

Pair programming is something I will never be able to think about objectively. It was forced on me by a manager who was trying to get me to quit (he could have just asked; I’d already decided to, having met my next manager) and it was an absolutely ghastly experience, giving me an all-night panic attack and PTSD, and I’m not what anyone would call “delicate.” Even its most strident advocates say it’s not for everyone and that it’s vital that the two developers work well together. Accustomed to privacy and solitude, and absolutely despising the guy I had to work with, it was an utterly ghastly experience and I quit my job the next day when the other guy ignored my saying I could not continue and obediently came to my office as soon as I arrived.

I can’t imagine it working. I’ve stressed the vitality of working uninterrupted and PP is one long interruption. In those three hours I don’t think I wrote more than a few lines of code and my desire for some privacy was like a savage thirst.

I worked one more onsite job after that but since 2010 it’s been 100% from home. I am starting another software job this week, cryptography again, but right now I am doing technical writing. The scrum/team fad has reduced offsite software work but I got hired as a writer in under 48 hours.

By the way, I don’t claim to be infallible. But I have had the experience many times of writing tons of work an object at a time and once all were finished, having pretty much everything work. Remember Marcus Aurelius; first principle is simplicity. I wrote boring, stodgy, bourgeois rock-solid and obsessively neat code. I only do optimizations in code that matters, thinking stability all the while.

But in 1995 I took on a telephony project for Intel where I was absolutely certain I was defrauding everyone; I was way over my head and hoped to pay a few bills before I got fired. Instead I delivered my client component working perfectly and made a lot of contributions to the design. That’s when OOP went from someone I was exploring to something I believe in with complete conviction.

Written by

American Software Developer living in Vietnam. Classical musician (guitar, woodwinds), weightlifter, multilingual, misanthrope • XY

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store