It’s not all bad, though. Agile and scrum are basically a fancy way of saying “communicate more”, and if you can get “the business” to talk to you more and all it takes is an overloaded word like “scrum”, go for it. Mostly, though, I hear “scrum” and “agile” and “tdd” as cop-out explanations used by developers to explain why they aren’t very good at their jobs.

• The project is late because the requirements were constantly changing.
• We didn’t catch the bug because we didn’t have enough time for testing
• 100% code coverage is impossible

All of these issues can be solved by being better at your job. Learn how to communicate with your customers. Learn how to budget your time. Learn how to write tests. Scrum and agile and tdd mitigate these issues, they don’t solve them. They force you to communicate, and write tests, but if you’re not good at communicating or writing tests, doing more of it isn’t going to help you.

Of course, if your manager is an idiot, then you’re screwed, and you will always have these problems.

But this article is less about whining in general and more about whining about TDD. Let’s commence.

Case Study: Sudoku Solver

Peter Norvig works at Google as Director of Research (I’m sure that actually means something) and before that he worked at NASA as some kind of AI genius/hacker. He’s a smart guy who’s been programming for a long time.

In Coders at Work, Norvig talks about a TDD experience of his involving an algorithm for solving Sudokus. It was interesting to me because I wrote a Java applet (shudder) to do that for a college assignment. It was an interesting problem involving recursion, threading, backtracking, memoization and other stuff that academics love.

What happened is that he wrote an algorithm to solve them, and then someone else, from the TDD community, saw it and attempted to write the same algorithm using test driven development: that is, by writing the tests first, and allowing the tests to influence the design of the algorithm.

It’s also important to know what you’re doing. When I wrote my Sudoku solver, some bloggers commented on that. They said, “Look at the contrast—here’s Norvig’s Sudoku thing and then there’s this other guy, whose name I’ve forgotten, one of these test-driven design gurus. He starts off and he says, “Well, I’m going to do Sudoku and I’m going to have this class and first thing I’m going to do is write a bunch of tests.” But then he never got anywhere. He had five different blog posts and in each one he wrote a little bit more and wrote lots of tests but he never got anything working because he didn’t know how to solve the problem.

The problem that the TDD guy encountered was twofold:

1. He didn’t know anything about Sudoku
2. He tried to solve that by writing tests

Tests are not a replacement for knowledge. That seems like a stupid statement, but it’s something that a lot of TDD/Agile advocates sometimes forget. They might complain that we’re not practicing scrum correctly, but practicing scrum correctly doesn’t guarantee that anything will get better. Instead of blindly following a wikipedia article to determine how to run your project or write code, you should figure out what’s wrong, and then solve that in the way that makes the most sense. You might even discover that you’ll start practicing scrum correctly as a byproduct of common sense. Common sense is why most development methodologies exist. Stuffing your current situation into the fad-of-the-moment is not going to solve your problems, although it might by accident. But I wouldn’t hold your breath.

Anyway, back to Sudoku. The TDD guy tried to solve the Sudoku problem by writing tests for a problem he did not understand, which meant whatever tests he was writing were totally worthless, which is something he actually admits in the very first article. After five articles and a great deal of code and a great deal of tests, a Sudoku solver did not exist.

From the first article:

Arguably this is a violation of YAGNI, but since I don’t really know how to start or how to know when I’m done, writing some Spike code in TDD style seems to me to be a good way to get my feet wet.

WRONG. A good way to get your feet wet is to do some research about the problem (the internet is your friend) to see if you’re going in the totally wrong direction.

My plan, subject as always to change, is to code something up in that way that I have, to see what happens

FAIL. “To see what happens?” I’m glad I don’t work with this guy. If you’re randomly writing code to determine if your plan is either absolutely perfect or absolutely idiotic, you’re doing it wrong.

Norvig solved the Sudoku problem by understanding the problem, understanding the solution, and then writing the code. He probably wrote some tests at some point, but they most definitely did not influence his design. What influenced his design was personal experience and a vast knowledge of search algorithms.

Of course, you aren’t going to have vast knowledge of every problem you’re trying to solve, but that’s not the point. The point is that writing tests first is not always the correct decision. If you don’t know anything about the problem or how to solve it, writing a test is not going to help you. All it will do is make you write a lot of code that is probably worthless.

Read for yourself:

• Norvig’s original Sudoku solver
• The TDD approach: 1, 2, 3, 4, 5
• The article Norvig references
• Another summary

Case Study: Wiki Engine

Recently, I decided to write a wiki engine. Why? Because I wanted to. I’m aware of the hundreds of other wiki engines, but it’s an interesting problem, and reinventing the wheel is a lot of fun, just make sure you’re doing it on your own time.

Anyway, I started and stopped several times, deleting large chunks and rewriting them as I went. That is probably not the best way to develop, but whatever. At one point, I wrote a test that looked similar to this:

public function testHeaderGetsParsedCorrectly() {
  $wikitext = <<<WIKI
!Header level 1
!!Header level 2
WIKI;

  $expected = <<<HTML
<h1>Header level 1</h1>
<h2>Header level 2</h2>

HTML;

  $this->assertEquals($expected, $this->wikiEngine->toHtml($wikitext));
}

Nothing wrong with that. It’s testing that the given wiki text gets transformed into the correct HTML. Pretty straightforward.

However, this gives me absolutely no insight to the design of the overall engine. I could easily write a function that will do this, but will it be the correct design? Let’s probe deeper.

I’ve written wiki engines before (they sucked). I’ve looked at other wiki engines, and done a bit of research into Lexical Analysis and certain kinds of parsers. I know a little bit about how to write something that parses something else. I didn’t really use any of that knowledge in my own personal wiki engine, because using yet another parser generator in a wiki engine written in PHP would be an impressive waste of my time, even from a purely academic point of view. But I digress. I was talking about why TDD was a bad idea in this situation.

All this test can tell me is that I need a function that should transform some text into some other text. How do I handle scoping? How do I handle block elements vs. inline elements? How do I handle escaping? Can the solutions to these problems be reused, or is it a one-off kind of thing that can be hard-coded in one place?

I ran into all of these problems after I had already written several tests. Everything worked, but the design was crap. There was no way I could handle a nested element (like say, a string of bold text inside a list item). I had to completely rethink my design. The amusing part is that the tests did not change, only my design. TDD utterly failed in influencing my design.

It could be argued that my tests were not good enough. I would argue that my tests are fine. The actual implementation of the engine is not something I care about. I don’t care if use a scope stack or if I keep track of nested elements in a different way, which is why my tests are only interested in results, not design. I could write some tests that look like the following:

public function testBoldIsAddedToScopeStack() {
  $wikitext = '__bold text__';
  $this->wikiEngine->toHtml($wikitext);
  $this->assertContains(array('type' => 'strong'), $this->wikiEngine->scopeStack);
}

Oh wait, that’s an absolutely terrible design, for several reasons. First of all, the scope stack should not be publicly available. I suppose I could add a public scopePeek() method that just returns the last pushed scope, but why? To satisfy a unit test? Testing should influence design, but you shouldn’t sacrifice design for testing. Don’t make methods public because you can’t test them otherwise.

Secondly, toHtml() is not incremental. When I pass text into it, I want HTML returned. I can’t just parse half of it and then check that it was parsed correctly; that makes no sense for a wiki engine. There isn’t ever a time when you would want to parse something halfway. Again, I’d have to sacrifice design to satisfy my unit test. That’s not going to happen.

Another solution is to just not close the scope, something like this:

$wikitext = '__bold text'; //no closing "__"

However, I want the engine to automatically close scopes when it reaches EOF. So the toHtml() method does that at the end automatically, which means that after I call toHtml() the scope stack will always be empty. I could move that functionality into another public function, but why would I want to expose that functionality publicly? There’s no reason. I always want to close scopes; I don’t want that decision left up to the implementer of the wiki engine.

In the end, there was no way for me to test that a scope got pushed onto the stack correctly. In fact, I realized that I really didn’t want to test that anyway. What if I wanted to change the scope stack to a queue? Then I’d have dozens of breaking tests because now the internal data structure is FIFO instead of LIFO. Is that something that should be tested? In my opinion, absolutely not. A long as the parsing works correctly, I don’t particularly care about the internal data structure of the engine. If performance is a concern, I can write tests to verify that parsing some hideously long whiny anti-TDD article takes x amount of seconds at the most. Then if a change to the internal data structure causes that test to break, then I know I’ve got something to fix. In that way TDD could influence my design, but up front, there’s no test that could have told me what my design should look like. I had to analyze problems that were hidden to the public interface and solve them without tests.

This seems a rather contrived example, but it’s an example that I encountered while trying to employ TDD to help me write some code (IRL, as it were). The fact is, this methodology just didn’t work for this problem. It was creating hindrances and forcing me to sacrifice a solid, safe design for the sake of testing something that didn’t really need to be tested. And it didn’t even give me the help I needed, which was how to construct the internal engine so that nested elements were rendered correctly. The fact is that I needed more experience in parsing engines before I could confidently design a parser that correctly handled nested scopes. This was something that required some trial and error before a design that solved the problem emerged. TDD wasn’t going to give me that no matter what kind of tests I wrote.

Conclusion

I’m not here to bash testing. I’m all for testing, in ways that might surprise you. I’m all for testing in ways that make people develop better. Some people just aren’t suited for TDD, and not every problem requires a unit test. In most cases, common sense will solve more problems than writing a test ever would.

And if anyone actually looks at my wiki engine, I had specific goals in mind, which is why it’s shoved in one giant class and uses arrays for stuff instead of objects. I don’t want to hear it.

Anyway, it turns out Brad Fitzpatrick (let’s call him fitzy) is kind of a programming prodigy. He got his start reading computer manuals when he was five, and started programming in BASIC when he was six. He recounted one anecdote wherein instead of doing his long division homework in elementary school, he wrote a computer program that worked it all out for him, including the intermediary steps, which he printed out, and then copied it in pencil to his homework sheet. That’s a high level of nerdity at a very young age. That’s like, a Jason Fox-level nerdity usually reserved for fictional situations involving an iguana and some kind of sibling blackmail.

fitzy is young, born in 1980, which means he doesn’t know Lisp. Which means he’s awesome. His primary hackery is done in Perl and C, but now that he works for Google, it’s Python, Java and C++, which Google apparently regards as the holy trinity of programming languages. He’s also the author of memcached, which is a huge surprise to me. If you had asked me who wrote memcached and who wrote LiveJournal, I would have said “a genius and an idiot”. Rarely do those two coincide.

Peter Seibel is revealing himself as less of the stereotypical brown-nosing, sycophant-ish interviewer as he calls fitzy out on some contradictions. fitzy is whining about the inflexibility of Java programmers (don’t even get me started about them) and their refusal to use the JNI for interoperability, and then later talks about how Google’s inflexibility with multi-language support is actually good.

The problem with that is that you end up writing everything twice, once for C++ and Python and all the other languages, and then once for Java. So if they could come up with a good embedding story or get over this fear of JNI, then I wouldn’t mind it.

Later, when fitzy is singing the praises of the Google App Engine, Seibel calls him out.

[fitzy]: The fact that App Engine gives you one button, “Put this on the Web,” and you write in one language, arguably a pretty easy-to-learn one, Python, is perfect. It’s a great into to programming – there are so many layers and layers of bullshit that it gets rid of.

[Seibel]: How does that fit with your dismay at the Java guys who tell you “Oh, Java takes care of that for you.” Isn’t that the same? “Well, App Engine will take care of that for you.”

[fitzy]: I don’t know. Maybe it’s because I know what’s going on.

Radness.

There’s also some good insight into the software development lifecycle at Google, including coding guidelines, standards, release schedules and ownership. Apparently it’s pretty wide open: the entire codebase is totally open to everyone, and anyone can submit patches or commit as long as they get it code reviewed and get the approval of the directory owner. That openness is probably why Google has been so successful.

I’m sincerely hoping one of the interviews in this book will reveal someone who’s not a bigot toward other languages other than the ones they are experts in. fitzy did not deliver on that.

One interesting thing about fitzy is that he uses the same question in every interview: implement arbitrary precision multiplication. Apparently that was a question on his AP CS test in high school. Let’s see what I can do:

function multiply($string1, $string2) {
	$len1 = strlen($string1);
	$len2 = strlen($string2);

	$result = array_fill(0, $len1 + $len2, 0);
	for ($i = $len1 - 1; $i >= 0; $i--) {
		$val1 = intval($string1[$i]);

		for ($j = $len2 - 1; $j >= 0; $j--) {
			$val2 = intval($string2[$j]);
			$value = $val1 * $val2;
			$index = ($len1 + $len2 - 1) - ($len1 - $i - 1) - ($len2 - $j - 1);
			addWithCarry($result, $index, $value);
		}
	}

	return ltrim(implode('', $result), '0');
}

function addWithCarry(array &$result, $index, $value) {
	if ($result[$index] + $value >= 10) {
		$temp = $result[$index] + $value;
		$result[$index] = $temp % 10;
		addWithCarry($result, $index - 1, floor($temp / 10));
	} else {
		$result[$index] += $value;
	}
}

It was an interesting interview. Joel Spolsky referred to him as the penultimate Duct Tape Programmer, whatever that means. I assume he meant to type “hacker” but misspelled it. It’s a common typo; the keys are like right next to each other.

Anyway, it’s clear from the beginning that jwz (as all of his friends call him) is a Lisp geek. So I pretty much hated him right away. Nothing annoys me more than people who think every language except the one they know really well is total crap. ALL languages suck. Except C#, which is God’s gift to man. But that doesn’t count because everybody already knows that.

The first couple pages are dedicated to the glorification of Lisp, and Lucid Lisp, and Common Lisp, and other things that only people over 50 know about, and the damnation to eternal Hell of Perl and C++ templates. I took a Common Lisp class in college and I came away with two things:

1. Recursion is awesome
2. I never want to touch Lisp again

There were other corollary (koar-uh-larry, dammit; I was a math major) things I learned, such as “Lisp sucks” and “Why are there so many parentheses” and “Why can’t any Lisp programmer format their code in a readable fashion.” All in all, it was a decidedly academic experience, which is where Lisp should have stayed: in academia. But I digress.

j-dub talked about his early days of hacking telephones, hating school, and generally being an all around Lisp pimp (Pisp?) by the time he was 15. His monologue on his days at Netscape were more interesting (unless you’re that other guy who knows Lisp) than his descriptions of his oddly creepy love affair with Emacs, or his equally creepy hatred of GDB. If I knew how to debug C code by looking at opcodes, memory addresses and registers, then that would have been a good read, but since I was born after the death of Hitler (Godwin’s law) I didn’t really understand any of it.

The more interesting parts were how he rewrote Richard Stallman’s C compiler, and him making fun of how everybody else’s code sucks. Because nothing is as much fun to a programmer as mocking and degrading the hard work of another programmer. That’s not a joke. I currently pay my rent by doing that.

The one thing which I truly enjoyed from the chapter was his description of the Gang of Four’s Design Patterns. And I quote:

Then there was another book that everybody thought was the greatest thing ever in that same period – Design Patterns – which I just thought was crap. It was just like, programming via cut and paste. Rather than thinking through your task you looked through the recipe book and found something that maybe, kind, sorta felt like it, and then just aped it.

…snip…

Then in meetings they’d be tossing around all this terminology they got out of that book. Like, the inverse, reverse, double-back-flip pattern – whatever. Oh, you mean a loop? OK.

That reminds of a story of how one of my coworkers was showing me a .NET IoC container called Unity. It’s nice, and gives you exactly what you’d want out of an IoC container for the most part. Like every other framework ever, it’s inherently confusing with plenty of misleading indirection. But it’s another thing to put on your resume.

Anyway, he was explaining how he was using the Unit of Work principle here, and… “Wait, what’s unit of work?” I asked. He replied, “Well, it’s basically a transaction, that, uh… enables you to safely… execute… some piece of code… and… uh…” I cut him off after 10 seconds of niners and said, “You had me at ‘transaction’”.