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.
_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.
How do you practice coding? How do you practice design?
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?
Chris Morris chimed in on this discussion, writing:
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:
Could this map to design and coding? Yes, I think it can. The ideas above follow a basic premise:
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.
Watch this space.
For those of you following the interviews with Dave and myself on Artima, the latest installment is now online..
This segment of the interview is about abstraction and detail: “because details are going to change, put the details where changing them will create the least amount of friction.”
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:
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.” :-)
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:
From Adobe’s Web Site you need:
You also need an installed and working copy of AFPL Ghostscript 8.0 or better from ghostscript.com. Here’s all you do:
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):
ps2pdf -I/usr/share/fonts/msttcorefonts … -dPDFSETTINGS=/default -r1200 $*
I suppose I could automate that last bit using a Samba printer driver, but there’s no need for the moment.
The end result? I’ve got a beautiful looking full score PDF file that is fairly small (about 45k per page) that I can e-mail to everyone else in the group ahead of our next rehearsal.
Ain’t technology grand?
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.
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.
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:
Am I having fun yet?
The Pragmatic Programmer
The original classic.
Learn to Program using Minecraft Plugins
NEW! Learn Java by building plugins in the MInecraft worlds.
Practices of An Agile Developer
Winner of 2006 Jolt Productivity award.