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.

Helpful/Annoying Software

Helpful people are annoying. Robert Fripp Aphorism

I can't stand chatty software that's trying to be helpful. I understand the motivation (Grandma needs help when she runs (or, more likely, walks) the computer) but I can't stand it. The first thing I do when encountering a fresh Windows install is to turn off all the cute animations, tips, offers for tours, etc. Bob or his illegitimate son, Clippy, anyone? My latest rant-inducing episode: I just installed Visual Studio .NET 2005. It very helpfully rewired my operating system to open all .java files in Visual Studio when I double click on them (because they must be Visual J# files, right?) Arrrgh! It's not like I can't change it back, it's just annoying.

As a public service, here is how to turn off those nattering ballon tips that appear over the task tray and never seem to go away. Thanks but no thanks:

Registry Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced

Data Type: REG_DWORD [Dword Value] // Value Name: EnableBalloonTips
Setting for Value Data: [0 = Balloon Tips Disabled / 1 = Balloon Tips Enabled]

Exit Registry and Reboot

Also as a public service, if you don't know about it, there is an entire web site dedicated (no, devoted) to fixing annoying software behavior: www.annoyances.org. Talk about a cottage industry with guaranteed growth...

Andy and Joel

I've been catching up on some geek reading lately. You know those books that twinkle at you from the bookshelf, when you know good and well you should read FooBar in Action book or some other varmint-ridden OReilly book, some books entice with their "You don't need to read me, you want to read me" smoky looks. Well, I succumbed recently. I had a trip and decided that instead of taking "normal" reading material, I would take two enticing geek-tomes. My choices? Revolution in the Valley: The Insanely Great Story of How the Mac Was Made by Andy Hertzfeld and Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity by Joel Spolsky. While at first glance, it looks like I picked the 2 books with the longest sub-titles, that wasn't the case.

Both books are great reads, but the interesting juxtaposition between them is the cultural whiplash you get if you read them side-by-side. The Mac book is all about figuring out The Coolest Way to Do This Thing That Hasn't Been Done Before, mostly in Motorola 68x assembly language. It's frightening to think that the first Macs (you know, the ones with a graphical user interface) had only 128K of memory! The overriding concern was uncompromising excellence. Joel's book is much more pragmatic. It has lots of good advice for anyone engaged in software development. In fact, lots of the advice that I foist on people in my Clean Up Your Code talk overlaps with some of Joel's advice. In one of the chapters he talks about the battle within Microsoft between the pragmatists and the visionaries.

Which brings up the interesting question: when should you be pragmatic and when should you be visionary? If the Mac guys had been pragmatic, we would have had a slightly sexier Applet ][e, not the Mac. But, being visionary doesn't mean that you win or even survive (see BeOS, Amiga, NextStep, the list goes on and on). That's the razor's edge we talk as technologists -- figuring out when to be pragmatic (and get paid, keep a job, and other mundane concerns) and when to say "What the f%#k -- I designing a dialog box with rounded corners because it's never been done before!". For more information about this dilemma, see Rails, Ruby on.

Aspects in the Business Layer

While I was at No Fluff, Just Stuff Boston this last weekend, I got into a conversation with a couple of interesting guys (sorry, fellows, I didn't get your names) at lunch who had attended my Enterprise Debugging session. This always happens at No Fluff, Just Stuff events -- the conversations with other speakers and attendees at lunch and in the halls is at least as interesting as the talks. Anyway, we started talking about aspects and how mainstream they are slowly becoming. I stated my position (which I blogged about earlier) that I believe that they will gradually make their way from the boundary layer into the business layer much like OOP did (see my previous blog entry about this theory). Neither of them bought it -- they were both convinced that aspects are forever going to reside in the boundary layer.

Then, I challenged them: name some cross-cutting business concerns. We thought about it for about 30 seconds and came up with several: legal, regulatory, sales & marketing. These are business concepts that cross-cut the traditional business layer, needing just a little attention in lots of places. And that's why aspects exist. This re-affirms my thinking that we will see this type of code more and more as aspects become more mainstream. It took 1 believer and 2 skeptics about a minute to find where aspects fit outside the business layer. Imagine what we would find if we actually put some effort into it!

Asperger's

Who does definition sound like:

This person has an intense and obsessive level of focus on things of interest and is often characterized by special (and possibly peculiar) gifts; one person might be obsessed with 1950s professional wrestling, another with national anthems of African dictatorships, another with building models out of matchsticks. Particularly common interests are means of transport (for example trains), computers, and dinosaurs. These interests are often coupled with an unusually high capacity to retain and recall encyclopedic amounts of information about the favored subject. In general, orderly things have appeal to these individuals, and they often manifests extremely sophisticated reason, an almost obsessive focus, and eidetic memory.

Sound like most of the developers you've ever met? Well, it's the Wikipedia definition of Asperger's Syndrome, a really mild form of Autism. Instead of seeing something like autism vs "normal" mental development, it's really more of a sliding scale. You've often heard that developers have special in-born characteristics -- I think these folks are a little more towards Aspergers than most. This explains a lot about the social skills and concentration abilities of really brilliant developers who don't interact well with the other humanoids. And why we can't get dates.

Update: Coincidentally, the very night that I posted this blog, I went to dinner with someone (very well respected writer and speaker) who has a child with Aspergers. He was telling me that this is a real problem in Silicon Valley -- geeks marrying geeks and having borderline autistic children. Talking to him made me realize that this entry might be construed to trivialize Asperger's Syndrome. That is not my intent at all -- it is a serious condition. However, talking to my friend drove home the point I made above even more strongly.

Leaving DSW

After 11 1/2 years, I'm leaving The DSW Group to take advantage of an extraordinary opportunity at ThoughtWorks. I have had a wonderful run at DSW, and both I and the company have benefited from my years of working there. I leave DSW on very good terms, leaving lots of friends (not just coworkers) behind. While Terry and DSW didn't want me to leave, he understands that I have a unique career opportunity in ThoughtWorks and he wishes me all the best.

Consequently, my email addresses at DSW will no longer be active. If you need to reach me, you can do so at nford <at> thoughtworks.com or at neal.ford <at> gmail.com. Of course, you can keep up with my travels, career, and hobbies still at www.nealford.com and here at my blog.

Thanks again to everyone at DSW for making my employment stay there extremely rewarding on a personal and professional level and I wish them all the best as I move to another chapter in my career.