I have been thinking a lot about the “short reach” idea, and tryng to reach beyond it to capture the thing that the good agile project teams have and several others are missing. At the same time, I’ve been reading up on some agile tools (including one by a guy I know) in my spare time. In addition, I am on a mailing list for multisite agile development. Finally, I have been pondering how to work this agile stuff when the developers cannot be co-located due to shortage of office space or shortage of common areas.

I realized that the whole “short reach” thing creates a kind of coercive immediacy.

I’m always trying to find newer, better, shorter, more powerful ways to explain what Agile is about. I suppose I’m some kind of obsessive about expressive power and economy.

Finally I decided that Agile, as I understand it today, is about the short reach.

It isn’t done yet, but I figured I would post my work in progress in the meantime for feedback. It’s a little article about the proper use of the VIM editor. I tried to mix in some keystroke quick-reference with the philosophy of the tool in a way that might make it a bit more accessible.

When it’s done (Ha!) I will probably find new places to store it, but for now it’s at my personal blog.

Don’t be afraid to offer corrective assistance, or to recommend sections.

Coding Standards are a good idea. Every team should adopt a coding style and standard, and stick to it. The code produced by that team should have a consistent look and feel that is devoid of individual preferences and fetishes.

For Agile, maybe the Two Things are:

• We can do better/faster this week.
• And this way next week will be better yet.

I have thought for a long time that code is liability, and that viewing code as a liability has the power to transform our art. I read articles about code-as-a-corporate-asset and most of them are pretty good articles about wringing the value from the code you have, but I still feel that there’s something essentially wrong about it.

Programs are a great means to an end. Don’t get me wrong, I’m in favor of having software and I’m greatly in favor of writing software. I think we would be in pretty poor shape without it. But I can’t call code an asset.

Today I was remembering a bit of advice I received back in the late 80s when I started trying to work with people more. I’d been a programmer for a while, and mainly survived by reading a lot and practicing what I read. I taught myself most of all the programming I knew (I did have some good mentoring peers). I wasn’t much of a people person.

A fellow named Kevin worked on a project with me in the DC area. One day he had the kindness to take me aside. He explained to me how to work with people. He taught me that when someone had an error in their understanding I shouldn’t tell them they were wrong, but rather tell them they were right except for the part where there was an error. He helped me more than he knows. We only had the one project together, and he went on to a different employer and I went on to become me.

He told me that a good coach doesn’t tear down his kids. He doesn’t tell they they stand like a sissy or throw like a girl. Instead, a good coach will let them know what’s right and what’s valuable about what they’re doing, and then explain what to add to their technique to get better results. And he doesn’t tell them everything all at once.

Now I’m a coach. I teach development methods, including agile methods, including TDD. I now work with people more than technology. I also work with a lot of other coaches from time to time. The best ones seem to intuitively understand when to criticize and how, and when to hold their tongues.

In the warm rush of enthusiasm and passion for the art of development, we coaches have to continually remind ourselves that it’s the poor coach indeed who slaps the kids around. We have to instead meet them where they are and look for ways to help them get the results they want.

Kevin’s lesson continues to teach.

The good news is, you probably already know. The bad news is, you probably know too much. This article describes Service Oriented Architecture in a simple and easy to understand way that is devoid of buzzwords and vendor spin. It’s the introduction to SOA that you haven’t been able to find anywhere else.

I find a lot of C++ programmers experience memory management differently than I do. I used to have the same kinds of problems that they have, but I learned an important rule: every heap object has exactly one owner, and n borrowers.

I’ve been fortunate enough to have spent most of the past three weeks teaching advanced Object-Oriented Design with patterns. The students have been wonderful and helpful and brilliant, so the classes have gone very well.

As I introduced students to Visitors, Adaptors, Chain of Responsibility, and mult-level State patterns, I was reminded of the problem that was rampant in the 90s: Having learned a catalog of patterns, many OO designers could not wait to put them into practice. Rather than using patterns to solve problems, they began to look for ways to apply these pattern solutions.