The View From Jerry’s Shoulders

In the software community, when we speak of the giants on whose shoulders we aspire to perch, names like Turing, Dijkstra, Wirth, and Knuth are often mentioned–names associated with the Computer Science side of software development. And there are giants on the hardware side: Von Neumann, and, if you want to go a lot farther back, Babbage.

There’s also a side of software development that doesn’t get enough attention, but is nonetheless critically important: The side that’s about people. Until some distant future when software development is fully automated, it will remain an endeavor that includes humans. And, by extension, our imperfections and foibles.

One of the giants on the people side of software is Gerald M. (Jerry) Weinberg. If you’re not familiar with Jerry’s writings, I envy the discoveries you have ahead.

Full disclosure: I’ve been a student of Jerry’s for many years, first through his books, then through his workshops, and finally through working with him on the AYE Conference. His teachings, wisdom, and subtle wit have had a profound impact on my career and life.

Where to start reading Weinberg depends on where you are in your career.

I came to know of Jerry’s work through the chance discovery of The Psychology of Computer Programming, a book that introduced many to the idea that there’s much more to programming than languages and algorithms. It’s a timeless book; human nature evolves much slower than technology. This is where I learned about ‘goal displacement’, which you’ve seen if you’ve ever been puzzled why it’s become more important to some developer that a system runs fast than it is that it works right. I’m not sure this book is the best place to start if you haven’t read Weinberg, but do read it at some point.

If you’re just starting out, Becoming a Technical Leader is full of excellent advise for planning and managing the external and internal aspects of your career. The idea that there’s internal stuff to be managed is a surprise to some, but if you’re going to be a leader, you’re going to have to learn to cope with a whole range of emotions, including frustration, anger, and hopefully elation. It’s worth re-reading every five years or so, if only to see how far you’ve come. This is the book that I gave away the most copies of when I was a manager.

If you’re a bit further along, Are Your Lights On? How to Figure Out What the Problem Really Is (with Don Gause) can help you avoid solving the wrong problems. Exploring Requirements: Quality Before Design will change the way you look at requirements. Though both were written before Agile, both still apply, since much can be lost in imperfect communication between customers and developers. The perils of mind reading remain even when there’s a Product Owner colocated with the team.

If you aspire to lead projects, any or all of Jerry’s four volume “Quality Software Management” series are a great investment. Volume 1, Systems Thinking, is one of the best introductions to a this very powerful technique that I’ve found (Senge’s The Fifth Discipline being the other). Volume 3, Congruent Action is especially good if your career path leads to management. It’s all about dealing with people effectively.

If you consult or advise for a living, The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, about the external aspects of consulting, is full of deep and useful advice. If you use the services of consultants, this book can help you get more value out of that relationship.

Perfect Software: And Other Illusions about Testing is in my reading queue, so I can’t recommend it yet, but a friend who has read it left the better part of a pad of sticky notes in his copy of the book.

Finally, Weinberg on Writing: The Fieldstone Method has some very good advice on writing for those of us technical folk who have to squeeze writing in to small blocks of time. You won’t find the writing techniques that you were given in school, and may wish that you’d had Jerry’s book instead.

That should be enough to get you started. Your next step is to pick one to add to your reading queue.

Since it’s pretty clear that I’m biased about Jerry’s work, check out the reviews of Jerry’s books on

Podcast Recommendations

Every so often a podcast comes along that’s worth several listenings. Today was number two for Nat Torkington’s “Design for the Future” talk from this year’s Webstock. Nat gives a history lesson that draws together the Crimean War, the Victorian internet (5 baud telegraph!), and Florence Nightengale (as an early proponent of reality-based medicine). He then looks at what those bits can teach us about current trends, looking in particular at the sad state of the news industry and at software development for cell phones. A thoughtful, informative, entertaining talk that I wish I’d been at in person. Fortunately, the audio quality is quite good.

I’ve been working my way randomly through the Webstock 08 recordings, and have been generally pleased with the quality of presentations. If you listen to technology podcasts, check these out. They’re a bit slow to download, but worth the wait.

Django and Rails

I’ve been using Django to build my latest scratch-an-itch project, and had been thinking about writing up a comparison of Django and Rails.

Ben Askins and Alan Green saved me the trouble.

Their presentation (which requires the latest Flash plugin) is a decent, balanced summary of the similarities and differences between the two frameworks. It’s 100 pages, but is paced for speed (and it’s a fine model for how to do compare/contrast presentations).

The only bit I’d add is that Django favors parallel development to a greater extent than Rails. With Django, you get to a clean separation between code and templates sooner, so that UI designers can be working on presentation while coding continues. And Django’s out-of-the-box admin interface supports lets people start doing data entry pretty much as soon as you’ve built your data models. Django doesn’t yet have migrations, though, so there’s more emphasis on getting your data model right up front.

Maybe one more bit: Rails has built-in support for AJAX and visual-effects, with several books that cover that support in depth. Django is JavaScript toolkit neutral, shiping with no built-in toolkit support (or no lock-in, if you want to think of it that way). For a sizeable project, I doubt this will be an issue, but for smaller projects this can give Rails an advantage.

If you’ve already chosen one of these frameworks, it may be worth your time to check out the other. There are good ideas in both.

Ajax Security

A security podcast I listened to during today’s commute caused part of my anatomy to retract in between a few chuckles. In Technometria: Ajax Security, Phil Windley, past CTO of the state of Utah, interviews Billy Hoffman, co-author of Ajax Security, on the subject of Web 2.0 security. In a presentation that avoided the usual doom, gloom, and “buy my services” approach, Billy detailed several exploits, both white- and black-hat; some funny, and a few that weren’t. Among the “how could developers be so stupid” exploits (hint: don’t write your own encryption algorithms) were a few that now have me double-checking code that I was fairly convinced was secure.

If you’re deploying Web-2.0ish stuff, even if it’s only using Flash on the client side, this one may be worth a listen.

Reading, current and recent

When Programming Collective Intelligence first popped up on radar, I had the impression that it was about massively multi-player games, something about which I’m only vaguely interested. On learning that it was about recommendation systems and related machine learning techniques, it went to the head of the reading queue. Programming Collective Intelligence is turning out to be very, very good. Good enough to demonstrate several simple, working recommendation systems (by page 28!), with complete code (in Python). I’m in the middle of the chapter on clustering techniques, and am making notes on how to apply them to a pile of data I’ve been sitting on.

Programming Collective Intelligence may not be a “game changing” book, but I think it’s going show people that some very interesting techniques are actually within their reach.

For the current “scratch an itch” project, I’ve been using Django, the web application framework for Python that seems to have the most mindshare at present. (Yes, yes, I know there are others, but I only have time for one, and Django is it.) Until The Definitive Guide to Django: Web Development Done Right appeared in print, working with Django meant reading documentation on the project website. Which leads to the first problem I ran into: The book is written against Django version 0.96 (the most recent “stable” release), while the documentation on the website reflects the latest code in the project’s subversion repository. And post 0.96, there’s some really good, compelling stuff, such as unicode support, functional testing support, and auto-escaping in templates, some of which isn’t backwards-compatible. (Fortunately, the Django team keeps a running list of incompatible changes on the project website.)

The other issue I have with the book is that (developer-level) testing gets mentioned only in passing, which seems to me to be a bizarre omission given the attention that’s given to testing by other frameworks and the general level of awareness of TDD and unit testing in the developer community. Fortunately, there’s a good testing chapter on the Django website.

That said, The Definitive Guide to Django is a well written, easy read. Any other issues I have with the book are really issues with Django itself, and how it compares (or doesn’t) to Rails.

On learning that Kent Beck was writing a book titled Implementation Patterns, I guessed that it would be about high-level construction patterns and pre-ordered it from Amazon. The book is actually a quite thoughtful discourse on how low-level implementation choices, such as choice of variable names and levels of abstraction in data types, communicate your intentions to later readers of your code, thus helping keep code bases viable. It’s also an excellent model for how to think and reflect about how you approach your work. I took away some better ways of explaining concerns I already had about coding, but lacked the words to articulate quite as clearly as Beck manages to.

Though primarily Java-centric, much of what Beck has to say about day-to-day coding maps to other languages (and the dynamic language side of me loved seeing Java referred to as “pessimistically typed”). There’s some material about Java collection performance at the end of the book that seems like filler, but if you’re working it Java it might be worthwhile.

This is a good book for mentors to hand out to “coders” who are making the transition to developer.

Speaking of Testing…

Elisabeth Hendrickson reminds me that there are a few spaces open in her Getting a Grip on Exploratory Testing workshop next week in Mountain View.

Testing is one of those practices that has suprising depths, and surprises in the depths. Many testers never get beyond doing an adequate job of it, which leaves expectations, and respect for the skill, low. That’s a shame, because good testers can save a project, and a company, a lot of pain and embarrasment.