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.

Meeting Pure Evil -- Socially

Last Saturday night, I bumped into Pure Evil while at a party thrown by a neighbor. I didn't think I was going to meet Pure Evil, and didn't even realize who it was until we had chatted a bit. But there he was, with a wine glass in his hand. He (and I won't mention his name for reasons you'll see in just a bit) is a former executive of several software companies and has been (and is currently) a consultant. He is now engaged in 2 lines of business: the first is to act as expert witness in dubious patent lawsuits for software patents that should have never been granted. The company he works for finds outrageous patents (they have found someone who has allegedly patented ecommerce -- the whole process) and sues major software companies. While ethically a little shady, this is not illegal. And I know that some smart people agree that you can patent software and processes. The ambulance-chaser way they are doing this, however, is a little creepy.

Turns out that this was just the appetizer. His other line of business is to sell small to medium sized business on as much enterprise software as possible. Things like SharePoint, PlumTree, Biztalk, etc. He really, really likes Microsoft back-office software because, as he puts it, "it's very easy to install". I asked him if most of his clients really need that much stuff -- wouldn't a wiki or something lighter weight solve the problem more elegantly? He was dumbfounded at the question because he can't charge big money for the care and feeding of that kind of software. He also professes to like .NET a lot because it is so extremely RAD. I asked him if doing development like that didn't cause problems during the maintenance phase of the application. After all, that's where you pay for rampant RADism, trying to find all that code you've sprinkled throughout your user interface in event handlers. His response: "We're generally through with the contract at that point, or leave for other reasons, so we don't have to worry with that too much". To summarize: sell them as much software as possible (that we don't have to understand very well), slam together applications that quickly become un-maintainable, then get out of Dodge before the repercussions hit. Clearly, this person and his company are trying hard to make sure that consultants are universally loathed.

People like this have the ethics of slave traders. Back in the day, slave trading was legal, and I'm sure it was very profitable...and morally repugnant. Mr. Pure Evil was also bragging about how much money he made last year ($350K). But how does he sleep at night? It made me realize first hand that you can randomly bump into people like this, who care for profit at the expense of ethics and brag about it. Excuse me, I've got to run take a shower...

Robert Fripp's Aphorisms

Robert Fripp's Aphorisms

If you recognize the name in the title, it is unlikely for the reasons I'm going to write about today. Robert Fripp was (and is) the guitarist and de-facto leader of the only surviving original progressive rock band, King Crimson. While the others (like Yes, for example) still tour in a Dinosaurs Roam the Earth mode (still playing their music from the 70's), King Crimson still tours with new music, and it is very new music indeed. Robert Fripp also founded a school for guitarists called Guitar Craft. It is not a permanent school, but one that moves from place to place, holding week-long classes for all levels of guitarist. I haven't been to one, but I've read about them. Really, they are as much about attitude and discipline as about playing music. There have been several graduates that have gone on to careers in music, most notably The California Guitar Trio.

However, this post isn't about that either. One of the rituals of Guitar craft is the recognition of aphorisms, or quotes that have special meaning in a specific context. The dictionary definition of aphorism is "a concise statement of a principle". Like:

The attitude that life owes us something, if not everything, encourages life to thwart our endeavors.

Taken in the context of guitar craft, these aphorisms relate to (at the macro level) life in general and (at the micro level) about the craft of playing the guitar.

We begin where we are.

However, there is another context with which to read these aphorisms. Fripp is legendarily disciplined, and there are numerous published examples of this trait, perhaps best is his own on-line diary (established before the term "blog" was coined). Another is the (unfortunately) out of print biography by Eric Tamm. These aphorisms, being "concise statements of principle", apply broadly to life and particularly leading a disciplined life. And that is something to which everyone should aspire. Reading and pondering these random aphorisms over the years has helped me write (or, more precisely, finish) books. And they have helped me finish arduous endeavors like Ironman.

Process is Intelligence getting to know itself.

Until you understand Fripp's context, some of the aphorisms don't make much sense. However, over years of reading, you understand the context and draw meaning from all of them.

Relaxation is never accidental.

If you want to see some Fripp aphorisms, go to the Discipline Global Mobile web site. At the bottom of the page is a random CGI script that randomly show aphorisms while you are on the site. One of my favorites (I have part of this engraved on the back of my iPod now) is one about the relationship between music and silence (in many ways, music frames a particular kind of silence):

Music is the cup that holds the wine of silence. Sound is the cup, empty; noise is the cup, broken.

In many ways, software development relates to music: a creative endeavor facilitated by dexterity, tools, and discipline. And, correspondingly, many of the aphorisms apply eerily to software development.

Address the process rather than the outcome.
Then, the outcome becomes more likely.

Enjoy!

Mourning Superior Dead Technologies

I was thinking this morning about buying a Macintosh, which lead me to ruminate on the fate of sometimes superior technologies that nevertheless fade away (not that I think that's happening to the Mac -- honest!). I can think of a bunch of examples off the top of my head: NextStep (I only heard about it, never got to use it), Magellan (the greatest navigation aid for a file system ever, never made it to Windows), Sprint (the best Word processor, never made it to Windows), and the list goes on and on. Even something like IntelliJ, which is creepy smart (side note: today, I realized that it will generate default variable names for you, based on the class type, even make good guesses -- for JButton, it offers both jButton and just button) -- I wonder if it can withstand the onslaught of Eclipse?

So, I reached a conclusion: don't mourn dead technologies. Use the best while it's available, but don't lament what could have been. I'll support Apple, IDEA, and the other technology stuff that I think exemplify good design. But, if market forces deign that they not survive, I won't fret -- just move on the find the next best thing. Besides, the really great ones sometimes live again, in different guise: OS X is really just NextStep reborn, Ruby is SmallTalk with some differences. Now, excuse me while I go shopping at the Apple site, with my iPod firmly implanted in my ears...

Software "Engineering"

It seems like every time someone talks about the job/craft/calling of writing software, they tend to end up with a bunch of tortured metaphors (engineering, woodworking, rock climbing, gardening, etc.). None of these analogies hold up past just superficial scrutiny. I think that it's a reflection on how different it ultimately is.

But to use one of these tortured metaphors for a moment, think about bridge building. I had someone at No Fluff, Just Stuff Philly say that her company had starting outsourcing much of their coding to India. I asked her how they judge the quality of the software. She said that she looks over it, and they have a software architect that comes to look at it periodically. Unit tests? None.

What if you decided to build a bridge? You outsourced all the design to guys who say they can build bridges, and you have someone who has built a few bridges look over the design when it comes in. Would you drive over that bridge? What makes bridges safe? It's the engineering science behind the bridge -- the mathematics of structures, derived over a great many years. So, why don't we apply the same rigor to software? We can't. We don't understand enough about it to quantify it in that way (and may never -- that's where the engineering metaphor breaks down again).

So, what's a poor developer to do? Actually, we do have a great option -- testing! It's extraordinarily difficult to build all the parts of the bridge and test them individually, then test it as a whole. However, because software is so soft, you can test everything. And you should. That's as close as we can get now to the rigors of a "real" engineering discipline. So we'd better damn well start doing it!

Toogle

I read about (and tried) an interesting new site today, Toogle. It performs a search for whatever you type in and returns it as an image generated from the words of the search, using different colors to mimic the colors (and therefor reproduce) the item you searched for. Trying to explain it is fruitless -- just go try it. I still haven't figured out how it decides what to return (a search for my name returns the JBuilder 3 Unleashed book, which is ancient history, not my most recent book), but it's still a fun idea.

Slowly Turning XMLese

Quote of the week, appearing on several other blogs (and in the March 14 issue of eWeek), attributed to Chris Maden:

"XML is like violence: if it doesn't solve your problem, you aren't using enough of it"

Nuff said.

Favorite New Eclipse Plug-in

Generally, I'm at the mercy of the client as to which IDE I use for Java development. Consequently, I try to find tools in each IDE that replicate favorite features in my favorite IDE (currently IntelliJ). Right now, I'm working on a project in Eclipse (the 3.1 M5a version, which has pretty good Java 5 support and isn't too buggy). One of the features I miss the most is the "Go incrementally find this thing", where "this thing" is a class name, part of a class name, or even some special versions of a class name (for example, to find TuPopupMenuManager, you can search for TPMM and it will find it). IntelliJ has this, and, no matter how many times you whack the side of the monitor, Eclipse does not...

...Unless you install my favorite new plug-in, GotoFile. It does just what I want it to, just like IntelliJ. And it even has preferences. Works with any version of Eclipse back into the dim and distant past. And, it's the Eclipse feature I use most during the day.

Aspects and Undoing

I was talking to Ramnivas Laddad (the person who knows the most about Aspects than anyone I know) at the Philly No Fluff, Just Stuff conference, hoping to dazzle him with an idea I had recently about a cool use for Aspects. My idea: using aspects to implement the Memento pattern for undo. The plan: use attributes in Java 5 to flag which fields are undoable, then write an aspect that injects the appropriate code into an inner class of the undoable class (side note: I prefer to use inner classes when implementing Memento, because they meet all the requirements of the Memento but don't break encapsulation because the inner class has a reference to the outer one's private fields).

Of course, someone has already had this idea, which Ramnivas kindly pointed out (check out Jon Tirsen's blog entries here and here). My only contribution to this discussion is the use of attributes in Java 5 to flag the undoable fields -- the rest had already been figured out. Just when you think you have a clever idea, inevitably, someone else has beat you to the punch. I do think this is a great use for Aspects, though.

No Fluff, Just Stuff Philly

Just got back from No Fluff, Just Stuff in Philly (my first NFJS of the year). I had a lot of talks this time (4 in Java, 4 in .NET), spread over 2 days. That was too bad because, as usual, there were a bunch of talks from other speakers that I really wanted to see. That's almost always the case.

No Fluff, Just Stuff attendees continue to surprise me with the level of discourse that occurs, both in the sessions and out. You are hard pressed to find someone to talk to that doesn't have something interesting to say. The expert panel was interesting (if for no other reason than to hear Ted Neward bicker with everyone). And the Birds of a Feather that I did with Scott Davis and Eitan Suez was also very interesting (we were supposed to just talk about Web Frameworks and User Interface stuff, but we ended up in a fascinating, wide ranging discussion covering outsourcing, certification, dynamic languages, and, oh yeah, web frameworks).

Fun stuff.

Woot!

My favorite new "Why Didn't I Think of That?" site is Woot! (www.woot.com). It is a shopping site that only features 1 item a day. They have a limited number of that 1 item, and when they are sold out, nothing happens for the rest of the day. Generally, it's something that is very deeply discounted. The next new item appears at midnight (central time) for the next day. How cool is that? The items vary widely, from robots to blenders (and that was just this week). Check it out. If you really get caught up, you'll end up staying up until midnight to see what the next item is going to be. The really good ones sell out fast (I'm not quite at that level yet -- I wait until the next morning...and end up missing out a bunch of times).

Instant Wiki

One of the best collaborative tools I've found in a long time for development projects is a Wiki because it is lightweight and free-form enough that everyone will use it. We've had one for a while at DSW and I'm stunned at how useful it is. There are lots of overblown document sharing systems out in the world (recently, I had the displeasure of using Microsoft's SharePoint -- ugh!), but the simple Wikis Just Work.

The one we've used for a while at DSW is Very Quick Wiki from SourceForge, a quick, simple, J2EE based Wiki. It took all of 15 minutes to setup and has run flawlessly for months.

I recently discovered an even easier one to set up -- Instiki. The instructions are so complex I'm going to reproduce them here:

Step 1. Download
Step 2. Run "instiki"
Step 3. Chuckle… "There’s no step three!" (TM)

OK, it's slightly more complex (you have to have Ruby installed), but not much. It stores everything in the filesystem (in a single portable directory if you have to move it, back it up, etc.), includes its own web server, and it Just Works. It is now officially my new favorite ultra-lightweight Wiki. And, it's Ruby based, which makes it even dearer to my heart!

Environmental Overcompensation

I travel a lot, and I've noticed a universal trend in places with inclement weather -- they always try to overcompensate for the temperature. For example, if you are in Houston in August and walk into a store, the air conditioning will have the temperature at 60 degrees. At first I thought what you are thinking now -- it just seems cooler because it is so hot outside. But, that's not the case -- I've looked at thermostats. Conversely, if you are in Grand Rapids in January and walk into a restaurant, it will be 90 degrees.

In each case, it seems that the people who live in weather-challenged places are trying to overcompensate. Almost like they are ashamed of the weather and they're trying to make it up by showing that they don't really like the ridiculous heat, they would rather shiver in July...

Aspects of Aspects

When I learned about Object-oriented programming, I thought it was about the coolest thing I had ever seen. The canonical example back in 1989 was shapes, so that you could create a polymorphic draw() method (this example still pops up a lot). So, I learned about OOP as a way to model problem domains. However, the only examples I saw for years out in the real world were all frameworks, like GUI frameworks or persistence stuff -- it was generally in the form of components to make constructing applications easier. Gradually, people started using OOP the way that I thought it should have been all along -- to model problem domains.

I think the same thing is happening right now with Aspects. While not as revolutionary as OOP, aspects still represent a key shift in thinking. But most of the examples you see these days are all in the boundary layers again -- logging, persistence, dependency injection, security, etc. Like OOP, once developers really grok what's going on with aspects, we'll start seeing it show up in the problem domain layer in places where it makes sense. Just like the really advanced OOP practitioners were doing it right early on, the aspect guys who are pushing the state of the art are pushing aspects into the problem domain right now. In 15 years, it will be as natural as polymorphism.

TV is the New Campfire?

Speaking of cavemen (as in my last blog entry), a friend of mine made an interesting observation. This is while we were camping (and those of you who know me and my policy on camping will understand what a rare occurrence that was), sitting beside the campfire. As you know, there is a hypnotic effect when you sit and watch a fire, either of the camp variety or in a fire place. Wright's observation was that the hypnotic effect may be genetic. Back when we lived in caves, it benefited those that sat around the fire at night -- more warmth, more personal interaction with the other fire-likers, and less likely to get eaten. And that TV is the modern campfire.

When you think about it, there are definite similarities. Both are flickering lights that encourage you to sit and stare. Maybe that explains the ease that some people have sitting and watching TV for hours on end. And, that may explain the default behavior of many people I know when they watch TV. They don't find a good show to watch (because there aren't any), they find the least worst thing and watch it. When a commercial or some other distraction comes along, they find the next least worst thing and watch it. I propose that most of the TV being watched isn't because it's really good, it's because it's there. A lot of TV isn't much more entertaining than a fireplace. Both seem to encourage that passive, vacant stare.

Maybe you could get the best of both worlds by setting fire to your TV?

Team Sports and Tribes

'Tis the season...

What with the SuperBowl just having passed like a storm, I started thinking about why people are so zealous about sports. Like the comedian said (I'm paraphrasing and sanitizing), oppressed people riot about the condition of their lives, while civilized people riot when their sports team wins!

I think this is a perfect example of deep-seated primate behavior leaking through the facade of civilized society. When we were in tribes on the African plains, it was a Good Thing to support your tribe, and behaviors evolved to reinforce that activity. The guys that didn't care for the tribe were off in the woods, acting as appetizers for saber-toothed tigers.

Today, this tribal tendency leaks out in the more or less harmless outlet of team sports. We've decided that countries as tribes is a bad idea (it took several wars, and some still aren't convinced). So, now we have our teams where we can attach our savanna baggage.