Andy Hunt, Pragmatic Programmer, Author, Speaker, Publisher

March 2003

March 30, 2003

Bill Venners’ interview continues with Part V on Artima.com. This time out Dave and I talk about our ideas on reversible decisions, adaptable software, and that wily and often misunderstood cost of change curve.

March 26, 2003

A posting about our latest Artima interview is now up on Slashdot.
As usual for Slashdot, a number of posters seriously misunderstood the article, but a few kindred souls got it, including this great quote by renehollan:

_Andy Hunt: But for me personally, almost every time I’ve taken that extra care to make a system flexible, it has saved me.
There’s an effect that I’ve named (what else) “Hollan’s Law”: The likelihood of something changing is directly proportional to the intensity of the argument that it never will.
Thus, when we see something in code that looks like it might need to be malleable, it probably will be._
Hollan hits the nail on the head; if our experience tells us that something is likely to be volatile, better listen to it! More on these ideas of metadata and flexibility are presented in our next IEEE Computer construction article, due out shortly.

This is an interesting topic that Pragmatic Dave Thomas and I (/\\ndy) have struggled with more than a few times. Dave’s recent blog piece on Verbs touched off a new conversation (and some interesting blog postings by Glen, Brian, and Chad). Chad’s post got me to thinking.

I’m a fan of the Jamey Aebersold CD’s (used to be tapes) with which you practice jazz improvisation. These tapes provide rhythm section backing that you can solo against in various challenging ways. The question then arises: can you practice coding and design in the same way that musicians practice?

Writing code is much more like songwriting than performing…it’s hard to make songwriting practice tools (What would this look like? “Write the changes to Autumn Leaves in all twelve keys”?) No, I don’t think transcribing the changes would be appropriate—that might be useful as a mechanical exercise, but not as a creative exercise.

So what would songwriting practice look like? Maybe it would include exercises like these:

Modulate from random chord X to Y over N bars in a given style

Given a set of chord changes, write a melody

Given that same set of chord changes, write another melody.

Evaluate each melody in terms of emotion, tension, relaxation, pitch center, distribution of long and short notes, unity and variety, etc.

Add a movement to an existing piece

Arrange a given piece in a different style (e.g., a Bach chorale version of “Autumn Leaves”, or a Reggae version of “America The Beautiful”)

Could this map to design and coding? Yes, I think it can. The ideas above follow a basic premise:

Given a scenario (some portion of existing work), solve a particular design challenge.

Given that same scenario, solve that particular design challenge a different way.

Evaluate your solutions against several metrics—there’s no right and wrong, necessarily, just see how it feels and what the implications of each solution might be.

Add a feature to an existing program

Change an existing program along some given axis

These sorts of exercises have the benefit that you don’t have to create an entire application from scratch just for the exercise, and that you get to exercise a particular creative skill at a time.

The trick of course is to make the scenario’s realistic enough to be helpful without getting bogged down in particular details.

The Aebersold series succeeds because it makes the exercise fun, limits the damage you can do (it’s in the privacy of your own home), and the scenario’s are “realistic” enough. The output of practice itself is disposable; you wouldn’t record your practice session nor would anyone else want to hear it. You then apply those newly-strengthened muscles to the real gig. Can we achieve the same thing to practice coding and design? Yes, we can.

March 18, 2003

I just received an advertisement for this year’s JAOO conference, billed as the Premier European conference on Java™ and Object-Oriented Programming (hence the name) and other software development technologies.

Out of the 30 topic areas listed in the ad, The Pragmatic Programmers (Andy Hunt and Dave Thomas) invented one topic and were instrumental in two others—for a total of 10% of the topics:

Pragmatic Programming: We invented it, and continue to lecture, write, and generate courses for it.

The Ruby Programming Language: Invented by Matz, we wrote the first English-language reference book and have been instrumental in bringing Ruby to the attention of developers throughout the world. Dave has been especially active in the Ruby community, and both Dave and I continue to write articles on Ruby and use it in our practice.

The Agile Alliance: We are 2 of the 17 founding authors of the Agile alliance, and have tried to infuse many of the sometimes over-zealous advocates of agile development with our own brand of pragmatism.

It’s just one conference, of course, and there are plenty of other topics in the world of software development worthy of debate, but it’s kind of fun to consider the prospect of “ten-percent today, tomorrow the world.” :-)

March 16, 2003

So I finished up a musical arrangement for the brass choir I play in, using the Finale scoring program, and I needed to e-mail the parts out before our next rehearsal. Now here’s the rub, Finale doesn’t make PDF files directly; you need Adobe Distiller to do that.

Being a cheap person and open-source advocate, I thought I should be able to use Ghostscript, but the scoring program is on Windows, and my good installation of Ghostscript is on Linux (with the nice True-Type fonts for Linux and some other useful tools). Windows doesn’t come with a generic PostScript driver, and using a kludgy printer driver like the Apple Laser writer limits your resolution to 300 dpi, which is not enough for a music score.

It took me a little while to find all of the relevant info from a couple of different sources, so I thought I’d lay out the process here:

You also need an installed and working copy of AFPL Ghostscript 8.0 or better from ghostscript.com. Here’s all you do:

Unzip the PPD archive and copy the ADIST5.PPD file someplace useful.

Run the PostScript windows driver installer

Tell it to use the “write to file” device.

Tell it to use the PPD you saved off in step 1.

Now when you print to that new printer device, you’ll get a PostScript file that is optimized for PDF output. You can set the resolution for that device to 1200 dpi on up, which is very handy (the original problem I had was that printing out Finale scores at 300 dpi looked really bad).

Drag that .ps file on over to the Linux box, and use Ghostscript to make the PDF. To make it easy on myself, I made a little shell script called “distiller” that invokes ps2pdf with the proper arguments (extra font path entries deleted for clarity):

This article reminds us that the ACM is once again sponsoring their annual programmer competition. This is where a team is given several hard computer-science problems to which they must produce correct answers in a short, fixed amount of time using a single computer.
Put another way, contestants compete against each other and an unrealistic schedule to produce software that’s just barely good enough under incredible time pressure with insufficient resources.
...and we’re teaching the kids what, exactly?
I have some suggestions: Instead of teaching competition, how about teaching cooperation? Get teams to work together to solve a much larger problem, with at least one computer for every participant, all networked together with appropriate collaborative development software. Instead of solving several discrete, independent problems, (since that rarely happens out here in the real world) how about solving a large complex problem with many interrelated facets? Oh, and the right answer isn’t enough. The code must be clean and extensible—and you have you prove that in round two. And forget about the the 5-hour deadline, you’ve got two weeks for your first iteration.
Now that, baby, is a challenge.

March 12, 2003

Apologies to everyone who’s been waiting for Dave’s and my latest IEEE columns to appear on the Pragmatic Programmer website. I’ve just posted the latest two articles, The Art of Enbugging and a piece on State Machines.

March 11, 2003

Here’s a little tidbit I almost forgot about; I came up with this for a talk at last year’s annual Ruby Conference.

One night, while reading the USDA Economic Research Service’s Agricultural Outlook for April 2001 (apparently there was nothing on cable that night), I came across the following amazing statistic.

Over a several-year period, the U.S. per capita consumption of Romaine lettuce increased 162%, to the point now where lettuce consumption is at a record high. Why? Largely because we are too damn lazy to even wash our own lettuce anymore.

The convenience of pre-washed, bagged lettuce outweighs the cost. At least in my grocery store, a bag of lettuce is easily three times more expensive than a raw head. Yet we buy the bag anyway, because you can just grab a handful and throw it on your plate.

Moral of the story: it’s got to be easy. It it ain’t easy, people won’t do it. This is a valuable point to keep in mind as we design systems, interfaces, methodologies, and so on. It’s got to be easy.

March 09, 2003

The March/April issue of Fine Woodworking magazine has an interview with James Krenov, a well-known and influential woodworker. Among his other comments he notes:

“I will always believe that it is a part of the human need to do something well and to be proud, rather than ashamed, of the work that you’re doing.”

Are you proud of the work you’re doing today? Are you having fun doing it? As Pete McBreen is fond of saying: it it’s not fun, you’re not doing it right. Too many people that I’ve met are quietly ashamed of their projects - maybe they blame their management, or their tools, or something else in the envrionment. They are certainly not having fun.

It’s not fun for me this morning, and I’m not proud of my meager output today. Maybe that’s just a symptom of “Monday-morning-itis”. It’s lunchtime here, which means I still have a few hours of daylight left. There’s still time to change the answer to that question by the end of the day, when I’ll ask myself one more time: