Enjoying the Passion

Last week was one of those great ThoughtWorks weeks in Chicago. There were lots of people in the office, it was a new hire week (with several people in orientation), and there were lots of gatherings to which I was either invited or managed to latch onto. It's always a mixed crowd at ThoughtWorks, with business analysts, project managers, and, of course, developer geeks. During one of the meals, I started talking about Language Oriented Programming (I know, a big shock to those of you who read my blog and/or been around me lately). The business analysts sitting nearby didn't have a clue as to what we were talking about. At one point, I turned to someone sitting next to me and apologized for the obviously obtuse (for non geeks) discussion. That reminded me of a similar situation that happened in Columbus, OH, when I met fellow ThoughtWorkers (a developer-type and a project manager). Of course, we started immediately talking about very esoteric software engineering topics. At one point, just as this week, I turned to the PM and apologized. She said: "That's OK, I'm just enjoying the passion".

Both events, last week and in Columbus, is a vivid reminder why I do this for a living and why I work where I do. How many people you know are really passionate about what they do for work, and so actively proselytize it to everyone they meet that can understand it? And in fact actively seek out people who can understand it so that they can talk about it some more? Even the non-techies at ThoughtWorks enjoy it, albeit vicariously.

Running Tests to Watch Them Fail

I was reminded again today by a fellow ThoughtWorker why in Java it's a good idea to write the test, run it to watch the test fail, then make it pass: what if you mis-spell the testing method, i.e., "tsetMyMethodToSeeWhatItDoes()"? Because JUnit uses reflection to find the methods to run as tests, it won't pick up "tset".

Which is why I think that NUnit v2 got it righter (is that a word?) by using annotations to mark the test methods instead of naming patterns. If you misspell the annotation, the compiler complains, which, in this case, is A Good Thing. Improvements are already afoot in the Java world -- TestNG already supports annotations (and JavaDoc tags if you are using 1.4) and several other features, and rumor has it that JUnit 4 will support annotations and some of the other TestNG features as well.

Beyond OOP

One of the questions that frequently comes up during the expert panels at No Fluff, Just Stuff is "What Comes Next?" What, in the opinion of the speakers, is the Next Big Thing? Consequently, I think about this probably more than most developers just so that I'll have a lucid answer at these panels.

One of my favorite characteristics of college was the accidental synergy that occurs between classes that you happen to be taking in the same quarter. For example, I took the automata class the same quarter as the compilers class, and there are obvious common elements. Even something as seemingly unrelated as artificial intelligence and philosophy creates a fertile ground for interactions.

So, how are these two things related? Lately, during my constant ruminations about What Comes Next, I've seen an interesting synergy between two separate but related concepts. Language oriented programming, my new favorite geek obsession, is one. It addresses the disconnect between the hierarchical nature of OOP and the rich semantics of language. The other day, I was talking to Obie Fernanadez, a fellow ThoughtWorker, and he is really into RDF and the Semantic Web. He's dealing in hierarchies, but in a different way. I am probably greatly injuring this assertion by my newness to this subject, but the Semantic Web folks maintain that, among other things, the problem with OOP is that it is basically context free. Hierarchies exist, but they don't relate in the rest of the world with other hierarchies -- each inheritance tree is an island. And properties that exist on classes don't have any context outside the class. In the real world, "address" can have separate meanings based on the context -- are we talking a physical place or a inaugural speech? The way our minds work isn't like OOP, where everything exists in a strict hierarchy. We have these "free floating" concepts like "address" that can be attached to the correct context. What's needed is context...and that's what the semantics of language provides that OOP doesn't already have. Now, this week at least, I'm thinking that What Comes Next is related to both language oriented programming, which provides needed context to the structure of programming, and semantic ontologies, which provides global context. These are fundamentally different things, but seems like there is some synergy to be found. More later...

Metaphor Shear

I was reminded today of a term I read about several years ago in the excellent essay "In the Beginning was the Command Line" by science fiction author Neal Stephenson. In it, he talks a lot about the layers of metaphors that make working with a computer what it is today. Without metaphors, you are stuck looking at a bunch of 1's and 0's (side note: every expensive piece of software you own -- Oracle, Application Servers, etc. -- are just 1's and 0's...it's the order they're in that's important). Anyone who has seen one of the original Osborne computers knows just how scintillating starting at blinking lights representing 1's and 0's is. The problems come in when the metaphors suddenly turn into vapor. I'll let the other Neal take it from here:

Anyone who uses a word processor for very long inevitably has the experience of putting hours of work into a long document and then losing it because the computer crashes or the power goes out. Until the moment that it disappears from the screen, the document seems every bit as solid and real as if it had been typed out in ink on paper. But in the next moment, without warning, it is completely and irretrievably gone, as if it had never existed. The user is left with a feeling of disorientation (to say nothing of annoyance) stemming from a kind of metaphor shear--you realize that you've been living and thinking inside of a metaphor that is essentially bogus.

The whole essay is a great read, with lots of insights into fundamental ideas about operating systems (if you think this metaphor is good, wait until you read his description of Windows vs. Mac OS vs. Linux as car dealerships). I think about metaphor shear anytime I'm forced down to the guts of computers or operating systems.

Language Workbench Sample Ported to Java

As I've blogged about recently, I'm updating my Building Domain Languages atop Java conference talk to incorporate information from Martin Fowler's article Language Workbenches: The Killer-App for Domain Specific Languages?. I wanted to show his example domain language sample in my talk but my talk is Java and his sample is in C#. So, as a public service to Java developers everywhere, I ported his sample to Java 5. This is mostly a straight port with a few differences:

• I used generics in a few places to clean up type casting
• The reflection stuff is different because that's where .NET and Java differ the most
• I cheated and created simple classes with public fields rather than properties for the target classes to make the reflection code easier

It is a complete version of the sample (including all the supporting files to make it run + IntelliJ project file). Martin graciously gave me permission to post it on my website and in my blog. Language oriented programming looks to me like the next big revolution in programming paradigms, and I'm spending a lot of time playing with this right now.

Berg's Chamber Symphony

Recently, I had the privilege to see a unique performance of Alban Berg's Chamber Concerto by members of the Chicago Symphony Orchestra, lead by Pierre Boulez, with Daniel Barenboim on piano and Pinchas Zukerman on violin. This concert was special because it re-created a landmark recording of this work by the same ensemble. The other unique thing about this concert: the musical work is only about 30 minutes long, but it was the only piece of the evening. Mr. Boulez and the entire ensemble came out and discussed the work (with examples) for 1 hour, 40 minutes, then took a short intermission, then played the work.


What makes this music so interesting that you can talk about it for 3 times as long as the piece itself? Well, it would take me over an hour to explain! Here are some examples, though. This piece was written in homage to Berg's teacher, Arnold Schonberg, who developed the 12-tone method of composition. The first theme of Berg's work represents Schonberg, Berg, and Anton Webern (another student) with the motif Arnold Schonberg Anton Webern Alban Berg (using the German alphabet). So, the main theme of the work uses the names of the teacher and students. Another example: the second movement is a palindrome: it plays up to the middle (signified by the piano's only involvement in the 2nd movement) the plays in reverse to the end, using different combinations of instruments so that it's not immediately obvious. There are lots of mathematical features in this music: the first two movements have 240 bars each, and the third has 480 bars.


Needless to say, this is a fascinating piece of music, made all the richer if you understand the context of the time in which it was written and all the ideas that went into it. Many people who don't like modern serious music don't have the correct expectations or context. Just as the movie Memento is different than Casablanca, they are both great achievements. The same is true for serious music.

Improving Your AIM

One of my biggest treats of No Fluff, Just Stuff symposia is the conversations you get into before and after. On the way to the airport in Orlando, Glenn Vanderberg, David Bock, and I shared a crowded airport shuttle (with a bunch of vacationers who didn't share our conversation). Glenn talked about some fascinating writing he's doing with feedback loops in Extreme Programming and David talked about the Agility Index Measurement. My contribution? A interested but dazed stare.

David has since blogged about AIM (nice acronym, very managerial) here. He's soliciting for people to help him develop a more or less objective measurement of just how agile a team really is. To quote: "the point is I WANT A WAY to compare the capabilities of teams implementing these [agile] processes." If this topic interests you, wander over to his blog and put your own $0.02 for what categories should be measured.

Riffin' at No Fluff, Just Stuff

One of the early histories of Saturday Night Live talked about the first meeting of the writers. Even though they had never met one another, and were from different parts of the country, they had a common language and thought that the same kind of things were funny. It was compared to jazz musicians, who can jam with one another even if they've never met, because they share the same vocabulary (and, dare I say, are familiar with the same problem domain).

The same thing happened last weekend at No Fluff, Just Stuff in Orlando. One of the speakers became ill at the last minute, and the organizer had to scramble to find speakers to fill his spots. I filled one of the talks, about fallicies in enterprise architecture, after never having seen the talk and having a whole 10 minutes to look at the slides for the first time. However, the talk came off really well -- I managed to talk for the entire ninety minutes, and got good scores. Because the problem domain was familiar, I was able to extemporize the talk, bringing my own experience to bear. This talk wasn't about tools or APIs, but about common fallacies developers face in enterprise situations. Well, I've seen a lot of that. Of course, I'm sure my rendering of the talk is no where nearly as good as the original and that the stories and experiences I bring are completely different from the original speaker. However, it reminded me of a jazz trumpet player showing up to a gig and saying "'Girl from Ipanema', extra solo after the chorus, and watch me for the finish. A-one, and-a Two, and...".

The Next Revolution: Language-oriented Programming and Language Workbenches

If you subscribe to Martin Fowler's blog, you've probably already read about Language Oriented Programming and Language Workbenches. He has very nicely encapsulated and clarified some of what I've been thinking for a while and added some badly needed organization to the topic. I've been doing a No Fluff, Just Stuff talk this year about Building Domain Languages atop Java, and it has been received very well in the cities I've where I've given it. Now, I'm about to revamp it and make it a Language Oriented Programming talk instead, taking the material I already have and adding discussions about LOP in general and workbenches. I'll also start showing JetBrain's (the makers of IntelliJ) cool new MPS meta-programming tool. It's still rough around the edges, but still very interesting. You have to have the early access version of IntelliJ (code named Iridia) and the MPS plug-in, but you can download all these goodies at JetBrains' site.

Centralized Help in Eclipse

As further proof that I embrace all IDE's (besides my beloved IntelliJ), I have just published an article on IBM developerWorks site about building centralized help in Eclipse. One of the really cool things about Eclipse is that everything important, including the help system, is built as a plug-in. This article shows how you can externalize both the built-in help and help you download with plug-ins into a central place. You can also turn the Eclipse help into a kind of wiki or other kind of collaborative document management tool without too much effort. The help system is quite flexible, as this article shows.

Windows eats itself?

I think my computer was trying to tell me something the other day:



So even Windows doesn't trust Windows Explorer anymore. Hmmmmm...

What You Know You Know, What You Don't Know, and What You Don't Know That You Don't Know

Blogs are a great way to show what you know and also a great way to show what you don't know (and can learn). I blogged yesterday about how to chain 2 ant calls together via Bash. Several comments showed that there is definitely more than one way to do this. You can use the "&&" in Windows to chain commands (which I had seen in the past and promptly forgotten). This also works in Cygwin's Bash because most of the stuff that works in the Windows command prompt also works there (Reason #432 to use Bash). However, I didn't know that you can chain targets together on the command line for Ant! I've been using Ant since early 2001 (I know the time frame because I wrote the first Ant article for Java Developer's Journal in June of 2001), but I didn't know about this handy-dandy little trick.

This illustrates, to me, one of the best reasons to have a public forum like a blog. You inadvertently learn all sorts of stuff if you are brave enough to try to teach others what you already know -- including stuff that you didn't know that you didn't know.

Reason # 431 Why You Should Use Cygwin/Bash Instead of the Windows Command Prompt

I'm working on a project right now that has a huge number of classes, and a corresponding huge number of tests. The whole thing builds via Ant (big surprise there). Currently, I'm writing code in a fairly isolated part of the project, and I've been working a few days on getting a new class Just Right. Getting it Just Right, of course, means unit tests and test first coding. The upshot is that I find myself needing to run the build target and then the target that runs the test suite over and over. I like to run both ant targets at the same time, but I need to know if the build doesn't work (e.g., if I get a compiler error, I don't want to run the tests). Rather than monkey with the ant build file to add this transient behavior, bash comes to the rescue. More and more, I do all my command line stuff in bash for reasons like this. Here is the command I invoke 30 or 40 times a day (all on 1 line, it may wrap here):


if ant; then ant runatest -Dtesttorun=com.thoughtworks.logging.AllTests; fi


This runs the default ant task (which builds everything). If the return code is 0, it then runs the "runatest" target. The test runs only if the build was successful. This little trick takes advantage of the fact that ant is smart enough to tell the underlying OS (regardless of the shell) if it passed or failed. The "fi" at the end is the "end if" indicator for bash.

Yes, you can create the same kind of little batchy kind of thing in Windows, but I never think to. It seems somehow more natural to me to think in terms of automation, shell scripts, and command chaining in bash than it does Windows. Maybe it's because bash is far, far more powerful than the command line tools in Windows. I never run anything in a Windows command shell now that I unless I'm forced.

Notes from Singapore, Part 1

When talking to the natives in Singapore, I and a friend (Terry) heard about Durian ("Stinky fruit"), which is a local fruit. I always ask about local foods from the natives to see what I can try that I haven't had before. It is against the law in Singapore to take a durian on public transport. And it is forbidden to take the fruit inside most buildings. However, several locals at the table said they really liked it. My new mission: try some durian. We ate one night at Newton food court, which had fresh durian, so we got one. Tom, who lives in Bali , is a big fan, so he would eat it if we didn't care for it. Well, they cut it open and Tom insisted that we eat it essentially holding our nose -- the flavor and the smell are only loosely related. So I tried it. Frank said it best -- it's like a mixture of vanilla pudding and onion, with a kind of fruit-flesh/fishy texture. I tried it. It was durian-like. OK, I've tried it. The problem is that, even though I only had a bite, I kept trying it -- the taste would not go away. I ate some other stuff. Still there. Drink water, beer, whatever -- durian. After a while you can sort of get rid of the taste until you have the misfortune of burping. Durian. Stronger than ever. It keeps growing. It was well into the next day until I could taste something else. It took Terry even longer. In fact, he developed a semi-permanent association between Tiger beer and durian taste. He may never appreciate Tiger beer again. The other interesting aspect of this fruit: it smells. And it gets stronger and stronger. It was still at our table because Tom (for whom I have new respect mingled with pity) was gradually eating the leftover durian (all the durian except for one bite each from the other victims). Ingo (one of the speakers) kept asking Tom to move it further away, because the smell, while not exactly the same as the taste, is the olfactory equivalent of the taste. After you have smelled it, you smell it everywhere. For the rest of the trip, we could tell anytime we got close to durian. Terry and I would look at each other at the same time: durian. Every open air market you come to sells that stinky stuff. And you always notice it if it's near. You have been warned.

Singapore Slung

After a long, brutal day of travel, I've made it to Singapore for the SDA.NET Conference, where I'm delivering 3 talks on .NET development on behalf of ThoughtWorks. Total travel time from Atlanta, from the door of my condo to the door of the Pan Pacific Hotel in Singapore: 28 1/2 hours, 20 of that in the air. I saw 4 movies and slept through 2 more on the various flights. But, I'm here! And I have a nice view of the convention center from my hotel window. I hope to enjoy my first trip here to this beautiful, clean city. More details later!

XML Hell

If you programmed in or used Windows, you are all too familiar with "DLL Hell", where DLL's get over-written by newer (or older) incompatible versions. Writing applications as piles of DLL's made sense when resources (particularly disk drives) were expensive, but not so much any more. However, this blog entry isn't about DLL Hell. It's about a related phenomena in the Java world - XML Hell.

One of the saving graces when Java first arrived was the freedom once and for all from DLL Hell. Of course, DLL Hell was really just the creeping scourge of versioning, and it came to Java with a vengeance in the form of XML Hell. I've been fighting with this little problem for the last few days. XML parsers and XSLT engines are supposed to be backwards compatible...the operational words there are "supposed to be". I'm working on a project where everything works great under JDK 1.4.x but causes blue smoke whenever you try to build it under Java 5. Turns out the problem is the version of the XSLT processor that comes with Java 5. One of the vendors of a 3rd party library in the application relies on specific behavior in an older XSLT processor that accidentally takes advantage of a bug in the older processor. The bug is fixed in Java 5, and causes everything to blow up at build time. Sigh....

The only platform that has gotten this right is .NET when using Strong Names (which can be a little cumbersome, but the fundamental solution is a good one). That's one area that .NET has definitely leap-frogged Java: versioning libraries. I hope that Java someday addresses this problem.

Management Mind Tricks, Volume 1

Over my career course as a consultant-type person, I've developed some patterns for dealing with irrational pointy-haired boss types and the technical sycophants that sometimes accompany them, and I've passed these on to friends for their own use. One has recently been used successfully and so I thought I'd document it here. Fortunately, the friend who used it also gave it the memorable name that patterns are supposed to have: "The 'Let Them Say Any Crazy Shit They Want' Mind Trick Pattern".

Here's how it works. If you disagree with someone on a technical point, and you know you are right and they are wrong (either from misunderstanding the problem, politics, underwear too tight, whatever), let them make whatever claims they want about their solution. The executor of the pattern calmly reminds them that his way is better for these calmly stated reasons. Let the arguer point to a phantom requirement, or phantom performance problem, or any other specious claim, and the executor remains calm and points out why his way is better. Repeat this pattern until everyone is saying that the executor's way is better. It takes quiet confidence, zen-like calm, and unshakable conviction, but it works. The recent application of this pattern by my friend (in conjunction with another pattern not of my devising) took 8 man-days but, in the end, they are doing it the right way.

This pattern only works if you are technically unassailable, and you have to concede if the arguer ever does make a salient point. However, the zen-like calm in which it is delivered still keeps lingering resentment over disagreements to a minimum. To be used sparingly in situations where nothing else seems to work and you are being asked to do something stupid for no good reason.

Hedonic Adaptation

Have you ever noticed that you are just one more gadget away from pure technology bliss? If only I could get the newest back-lit, bluetooth, high resolution, 64 Mb turnip twaddler, I wouldn't ever need another gadget. But a funny thing happens a week after you get back from the electronics store...now, you need something else. I had recognized this pattern in myself, but recently discovered that, not only am I not the only one, but psychologists have named this: hedonic adaptation. This comes from studies of happiness. For example, lottery winners, right after they win, report that they are very happy. However, they quickly adapt, and, after a while, their sense of happiness and well being returns to their pre-winning levels. The same is true for technological innovations. No matter how dramatically a bit of technology improves our lives, we quickly take it for granted and start looking for the next thing. This helps explain why people in 2000 were not measurably happier than those in 1900, even though technology has made our lives astoundingly easier.

For more information about this, check out this fascinating article Technology and Happiness in Technology Review. And, as much as it seems like it, that new Powerbook with Tiger on it won't make you blissfully happy...Well, maybe just a little. I'm willing to try.

Test-first Mine Sweeper

I don't play many games on computers (too much other stuff to do). So, some of you will be shocked and mortified that I only recently discovered that, in Minesweeper, if you both-button click on a number, it will either highlight the un-clicked cells adjacent to it or go ahead and uncover cells that you would know are already mine-free. It's harder to explain than to do it. Some of you can't believe that anyone that has been using Windows for better than 10 years is just now finding this out, and the others can't figure out what I'm talking about. For those who don't know, dash over and try it...I'll wait.

Back? OK, here's the thing. When I do test-first development, I write the test and go ahead and run it, knowing full well that it will fail. It's sort of a Zen thing, I guess. I know that it takes a little more time, but it's part of the satisfaction of seeing it fail then succeed shortly afterwards. Even this isn't so unusual.

I've found that I do the same thing when I play (what is to me) the New and Improved Minesweeper -- I do test-first clicking. Even if I know that there is only one possible uncovered cell nearby that this number can reach, I still double-button click on it to satisfy myself that it is the only one. It's test-first Mine Sweeper.

I really should get out more.

Google Desktop Search + Java

One of my favorite pieces of software that died while trying the Extreme Sport of transitioning from DOS to Windows was Magellan. It was a file manager for DOS that indexed your hard drive, then showed you the results in a list. Searching for some phrase that was on your drive was instantaneous. Now, you can get the same thing with Google Desktop. My only complaint is that you can't tell it what types of files you want it to index -- it defaults to things like Office documents and emails. But, lo and behold, there is a plug-in API. And someone has written a Google desktop plug-in that indexes Java source files. Plug it in, let it trundle a while to build the index, and you have instant access to interesting stuff you have in your Java files. Great for spelunking around a deep and wide object hierarchy. Because it's indexed, it's as fast as Ctnl-N in IntelliJ for finding classes, but it works over the entire file system, even on really large drives.

It indexes on the fly (it's amazing how fast it picks up new files), waiting on CPU idle time to kick in. The indexes on my machine currently take up about 1.5% of the disk. It changes the way you search for things, though...I'll give up 2% of my hard drive to get instant access to needles in a 30+ GB haystack.