Now there's a title to grab your attention! But I'm serious!
First, a little background on me: my PhD was one of the earliest on the automatic creation of optimizing compilers from formal machine descriptions ("Machine-Independent Generation of Optimal Local Code", CMU Computer Science Department, 1975). After my PhD, I spent three years at CMU as a senior researcher on the C.mmp multiprocessor computer system which used our home-grown Hydra operating system, a secure, capability-based operating system. I then went back to compiler research on the PQCC (Production Quality Compiler-Compiler) project, which ultimately led to the formation of Tartan Laboratories (later, just Tartan, and now absorbed by Texas Instruments), a compiler company, where I was part of the tooling group. I spent a decade-and-a-half writing and using performance measurement tooling.
This essay has several parts and represents much of my own experience. The stories I tell are true. The names have not been changed, although a couple are carefully omitted.
Friday, January 30, 2004
Monday, January 26, 2004
I'm pretty happy to be working at ThoughtWorks. One reason is XP. The whole company has taken up the XP mantra and we all happily hum it to ourselves while coding in our sleep. And it gets results. I look forward to seeing the faces of skeptical clients as we present these low defect project cases to them: shock, disbelief, delight.
Sunday, January 25, 2004
I noted before about the changes in the upcoming Python 2.4, which at the time amounted to
none :-). But I just checked back and are some now. If I weren't spending so much of my work time immersed in Java idiocies (mixins anyone?), I'd be spending a lot more time promoting Python within ThoughtWorks.
Friday, January 23, 2004
Sunday, January 18, 2004
BileBlog has a strong rant against test-driven development. I see his point. Personally, I uses a hybrid of TDD and code-first development, depending on what suits my whim. More to the point:
The problem with the TDD crowd is that they're unwelcome guests in a world that doesn't want or care about them. I'm very sick of TDD bigots being snooty, getting offended, and angrily tugging at their unmentionables every time they see a unit test that doesn't meet their ludicrous standards for what constitutes a unit test.
So, let's look at a concrete example. I'd like to test a servlet. The servlet is standalone, it doesn't call anything else, it just Does Stuff. It's a standalone unit for all intents and purposes. There's no webwork, struts, or any such crap involved. I don't want it to be a wrapper with the work done in a POJO. I just want my single damn servlet. Sometimes a servlet is just a servlet.
The TDD asshats will now start furiously chewing on their desks if you try to use any sort of real container in your unit test. To them, that pollutes the test, you're in fact testing the container too and not just your servlet. That, astoundingly, makes it an invalid unit test (or at best, crippled, awkward, unwieldy).
Even more incredible are the suggestions they offer up to overcome this crippling (!) dependency. Suggestions that range from not using a servlet, to using mocks, to getting some POJO's involved, all so that you can have clean unpolluted tests.
To make some of my fellow ThoughtWorkers aghast, I have to agree here with the rant. And he, too, dances the hybrid dance:
I don't write my tests first. I know very few people who do. It's awkward, fragile and unintuitive. For those who enjoy it and find that it's none of those things, great! At best, I'll do a mixture of the two, and have something vaguely functional, then write a testcase and make sure it tests all the conditions I'd like it to pass under even though I know that it'll fail.
The most important thing is not to follow fashion, but do what works for you. Or just Do The Right Thing:
Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called PC loser-ing because the PC is being coerced into loser mode, where loser is the affectionate name for user at MIT.
The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing.
The New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex. Besides, programmers could easily insert this extra test and loop. The MIT guy pointed out that the implementation was simple but the interface to the functionality was complex. The New Jersey guy said that the right tradeoff has been selected in Unix -- namely, implementation simplicity was more important than interface simplicity.
The MIT guy then muttered that sometimes it takes a tough man to make a tender chicken, but the New Jersey guy didn’t understand (I’m not sure I do either).
Thursday, January 15, 2004
Wednesday, January 14, 2004
After much righteous struggle, my programming pair figured out how to make a reuseable tile for Sruts, testing and all. The pieces are five:
- An actual tile (JSP file) and matching entry in the tiles definition file; this is fully reuseable
- A controller and display adapter to populate the tile, and tests for the controller; use an abstract base controller and test for the tile and specialize for each specific use
- An action and form to read the tile back, and tests for the action; use an abstract base action and test for the tile and specialize for each specific use
- Glue in the struts configuration file to hold it all together
- And methods in the service layer as data sources and sinks for the controller and action and tests
And all my tests are green.