PragDave

This Old Dog Learns Something

I make a habit of trying out new things when I come across them. I end up trying a lot of stuff, and I tend to make pretty good evaluations fairly quickly. I first came across Ruby when it popped up in a search engine’s results when I was looking for something completely different. It’s the same with most tools and technologies I use.

A while back I tried the Eclipse development environment. I had problems running it on my Linux box, and my Windows box at the time was too slow to make it usable. Back on the pile it went. Six months or so later, a client standardized on Eclipse, so I got the latest version and tried again. I gave it a couple of weeks, but never got it to work for me. I couldn’t reliably synchronize with their CVS repository, the project builds were inconsistent, and it crashed on me fairly frequently. Back on the pile again.

In the meantime, I was smugly going around telling folks that Eclipse wasn’t for me: I’m an Emacs guy, after all.

Well, it turns out I was wrong.

Andy and I just started a new project, so I decided to give Eclipse the old college try just one more time. To my total surprise, it works for me. Not only does it work reliably (admittedly on a fairly small code base), but I’m finding that I’m more efficient than I was using Emacs. Some stuff is just plain clever (like the way it reflects changes in my package structure in the underlying CVS tree), and other stuff is just nice (like the error bar next to the source window which is surprisingly useful when you’re trying to do refactorings not supported by its build in tools). I also like the way it lets me program by intent: I can write a code fragment assuming that the methods I need exist, then ask Eclipse to create stubs for them automatically.

It isn’t perfect, and I’m starting to see why I had problems initially. When past clients talked me through setting it up, I’m not sure they did things in the most straightforward way. This is a gripe I had (and still have) with Eclipse; they are 27 ways to do most things, but not all of them work well (or work together, I’m still not sure). Importing an existing CVS tree into your workspace is not intuitive. Accessing the repository in the first place takes some guessing (right-clicking on a blank list of repositories gives you the option).

But I still like it, and I’m going to see the current project through with it. And I’m glad that I didn’t give up on it totally when I was trying it out; I feel I’m now more productive using it.

Microsoft folks talk about "flipping the Bozo bit;" don’t write off fellow developers just because they may not get something, or because they may have made a mistake. I guess the same applies to tools and technologies too.

Vicarious Seat Backs

After a hellacious trip across to Norway for rOOts (note to self: never fly Lufthansa transatlantic), the return came as a pleasant relief. Not only was the SAS flight half-empty, letting me claim an entire center row to myself, but their new A340 had something I hadn’t seen before: nose and belly cameras wired into the seat-back video displays. A couple of touch screen menu picks, and I had one seat-back looking forward, one looking down, and a third on the moving map. It says something about the state of mind that you get in to on long flights that I started playing a game, trying to tie moving map features up with the downward-pointing camera. It turned out to be easy (which I guess is what you’d expect): just as the moving map said we were over the coast of Iceland, a rocky shoreline scrolled beneath us. Coming across Canada approaching the Great Lakes, most of the larger rivers on the map seemed to tie in with what I was seeing below. Looking out the front and seeing the runway appear through the murk during our final in to O’Hare was a nice way to end the trip. +1 SAS.

First Kill the Architects

I’m over in Bergen for the rOOts conference. Martin Fowler gave an interesting 30 minute talk on the role of architecture in software development, and on how the forces that drive architecture also drive other aspects of the overall process. He started by mentioning Ralph Johnson’s discussion of architecture; we define architectures to document the things that we perceive as being hard to change. Being agile, Martin then went on to say that the role of an architect is to make himself redundant: to find ways of implementing systems which can roll with the punches, and where everything is amenable to change. As an example, he talks about databases and schemas. Conventional thinking tells us that database schemas are hard to change: once you code to a schema, every change involves updating the database, the code, and also all the data affected by the change. As a result, people tend to treat schemas as scary things: we define them and then code around them. At Thoughtworks, though, they have developed techniques for incremental migration through schema changes: the database, data, and code all update in parallel. As a result, the schema no longer has to be defined up front: is is no longer an architectural element.

The driver for all this, of course, is flexibility: we need to find ways of writing applications that work in the face of a set of volatile requirements. Cut down the number of up-front constraints, and we increase our degrees of freedom. If also helps us start delivering earlier, allowing us to get feedback ad refine our applications as we go.

The alternative to killing all the architects, of course, is to kill all the developers. Rather than spending time coding flexible applications, find ways of throwing together disposable solutions to business problems at greatly reduced cost. Don’t worry about flexibility: if the application no longer works when the environment changes, throw it away and write it again. If the cost of code is small, then the investment can be written off in almost no time.