I have spent the last two days with Mary and Tom Poppendieck at one of their Practitioners Courses, and I find myself inspired. Among the interesting moments for me was a point at which I reached an unsettling notion: are we “too Western” to design software well?

I came to this question while watching course attendees talk about the problems in their organization. As they explored the flow of value through their IT organizations, I kept hearing about managers interrupting the flow and of centralized decision-makers as bottlenecks, when it occurred to me: I’ve heard about these problems in code before.

Specifically, I heard the word “manager” and my mind wandered towards thinking of Manager classes in a code base, rather than flesh-and-blood managers. In that wandering instant I saw a connection between the two kinds of managers: human managers have mostly commonly been trained over the last century to micro-manage, make important decisions and direct their people; and Manager classes do essentially the same thing in code. Now, while our ideas of management have changed in the past 50 years, mostly due to the work coming out of Toyota, we are still over-run by micro-managers whose effectiveness is limited.

It’s quite similar with code. In spite of the object-oriented design movement and the advance of test-driven development with its emphasis on simple design, procedural thinking dominates, even in code bases that use object-oriented languages. Most programmers approach code with Procedural Mind, even when they believe they want to design with objects. Even when I teach people how their can arrive at excellent designs by following four simple rules, Procedural Mind dominates.

So I wonder: given the parallels between tactical, command-and-control management and highly procedural code where important decisions are centralized in these Manager classes, and given that our most common human management style is a relic of western military thinking, and given that it perpetuates in part due to culturally-entrenched ideas about managing people, are Western programmers conditioned against excellent design? Are we mostly doomed to gather our code in Manager classes, rather than distribute responsibilities evenly and focus on object interaction?

Are those notions simply too Eastern for us?

Discuss

I ran across Cédric Beust’s article Agile People Still Don’t Get It again, and I just wanted to point one little thing out for you, for him, for everyone. He writes about a presentation he attended that illustrated why agile people still don’t get it:

One of the first slides that deeply troubled me claimed the following: Tests are (executable) specs; (and) If it’s not testable, it’s useless.

Cédric went on to show a number of examples of algorithms that aren’t worth test-driving and useful code that isn’t testable. All very good, all understood, all makes sense; but all in his acerbic, off-putting style.

Cédric, I love you like a brother, but this Bileblog nonsense is wearing thin. We’re not 21 any more; and it’s time to reach a wider audience of more thoughtful people through sensible and reasonable discourse. I’m afraid that, in this case, your conclusion does not at all follow from the hypothesis.

It’s true that there is a steady supply of agile evangelists out there that push agile like a religion, but not only is none of this is news, but it’s a natural part of the evolution of any idea. I went through my proselytizing phase. It was at a time when my primary concern was getting to practice agile, and I thought that if more people liked it, more people would give me the chance to practice it. Instead, I started taking myself more seriously as a business person, made more money, and that has translated to more free time to practice whatever I want to practice. This allowed me to feel more secure about my own agile practice and my own effectiveness as both a practitioner and consultant. Not everyone takes the lead in their careers like I did, so when you see someone lashing out, proselytizing, don’t hate them, but help them. There’s something missing in their lives, and it’s worth offering them a chance to find out what it is and fill the void. People did that for me, and I’m willing to do that for others. Are you?

On the question of the agile religion, you might think Bob Martin is one of the High Priests of Agile, but as early as 2002 (!) he warned us about this behavior, and I take away two key points from his message. I believe it was at a dinner talk at XP/Agile Universe 2002 that he invited us not to make absolute statements about agile.

Those absolute statements served us well to rile up the visionaries (in the Crossing the Chasm sense), but as we reach the mainstream, statements like these hurt more than they help. I prefer to tell people that the more they test, the better their features are; and the more testable their features are, the more easily maintained they are. They seem to respond to that, especially when I show them how that is. I still astonish people, as unexpectedness is a key component of a sticky message, but I prefer not to use divisive, absolute rhetoric to do that. I use different techniques for that now.

I believe it’s become more important to be less overtly provocative, and instead be clearer with our advice. I don’t think most thoughtful agilists will claim that they write production code the way they teach others to do it; but this is not a simple case of “do as I say, but not as I do”, but rather a case of the student needing to learn the lessons by following some useful rules before leaning too much on under-developed judgment. Not everyone agrees that we should give novice rules to novices, but it works well for me, so I do it. This means that I sometimes tell people “delete that code because it isn’t tested” or “stop and refactor the code until it’s testable”. I find it an effective way to help them learn and develop judgment, the skills I believe will serve them best. I tell my students directly:

Do I take tiny steps like this every time I write code? No. Do I think you should take tiny steps like this when you write code? Yes. Why? Not because it’s the best way to write software, but because you learn a lot when you do it and, more importantly, when it’s 2 AM, you’ve been called back from vacation, you’re performing surgery on a production system that’s losing $100,000 per hour of downtime, you’ll be glad you can work in such small steps.

More succinctly, I’m more up-front with people about the pedagogical aspects of what I do. They seem to respond well to that, rather than patting them on the head and saying, “No, trust me, just write the tests. You’ll learn.” I’m sure there are plenty of trainers out there, agile and otherwise, who treat their students like children, rather than adults. They make absolute statements of the type that Cédric is right to complain about. I just wish he wouldn’t make it seem like a uniquely agile problem, and I wish he wouldn’t lump us all in one bucket. I suppose it’s convenient to do that, but it’s not true.

In fact, it feels downright religious to do so.

Discuss

In the process of learning to use OmniFocus to Get Things Done, I have changed the way I group projects into folders. I started by grouping projects by purpose. I later realized why OmniFocus doesn’t have task priority: it has project priority built in, just by moving projects around in the Projects view.

This made me think that I should throw away most of my task due dates, which I’ve done, and replace “which task to do next” with “what are the next actions in my projects”. This encourages me to prioritize projects, rather than simply dump them into the Projects view and, perhaps, collect them by related purpose. Now, I group projects by “urgency”, which I happen to measure in how happy they make me: do they take care of me? do they generate more passive income? do they help me spend more time with cool people?

Incidentally, notice that I wanted to hide some of the information in the “urgency” picture, but not in the “purpose” picture. That’s a clue in itself about what I should really be working on: the stuff I don’t want you to know about until I release it. :)

So if you have found that your projects list has grown out of control, maybe you should re-prioritize your projects and group them by urgency, rather than purpose. You could even hide the “not important, not urgent” projects and look at them only during a periodic review.

Discuss

I used to be the type of person to miss meetings and deadlines like crazy. This happened to me primarily because I tried to keep everything in my head. I have tried a bunch of little techniques for reminders, and nothing really worked until I started using Backpack. Here are the things I tried.

• I tried writing things in a pocket-sized notebook, believing that writing things down increased my chances of remembering them. This didn’t work, either because I forgot to look at the notebook every day or, quite simply, I’d lose the notebook.

• I tried writing things on index cards, since I used index cards effectively as part of my software practices. This didn’t work because I wouldn’t carry the cards around with me enough nor look at them enough to recall appointments.

• I tried a PocketPC, but frankly that became little more than a way to keep myself entertained while waiting for the bus. My subconscious recognized how useless it was for me and helped me leave it “by accident” on a flight from Philadelphia to Toronto.

• I tried calendar software on my computer, but found it hard to get appointments onto the calendar, because I didn’t always have my computer handy. I tried a workflow that involved index cards that I later transcribed to computer… and it just didn’t work, so I abandoned it.

Now I use Backpack, a service from the nice folks at 37signals. Backpack reminders are flexible, simple and quick to use. I set up reminders for tasks that don’t have a definite due date, but as a “tickler” in the Getting Things Done sense of the term. I have reminders set five years into the future on Backpack as a testament to how much I believe I’ll be using the service in the years to come. While I tend to use Backpack mainly for reminders, I also use the Writeboard to share composition space with friends and family.

So if you’re looking to get re-organized, I recommend reading Getting Things Done, grabbing a copy of OmniFocus (you are a Mac user, aren’t you?) and subscribing to Backpack. You’ll be glad you did.

Discuss