Martin Cron

Alan Shalloway, the NetObjectives chief and one of the world’s most prominent Lean Software Devleopment evangelists created a Yahoo! group around “lean-agile-scrum” and invited the NetObjectives/VelocityPartners people (me included) to participate. So I do, sometimes.

I’ve been haunted (haunted I tell you!) about a question that came up a while ago. I’m too lazy to look it up, so I’ll just paraphrase.

“I’m interested in putting up some big visible charts/information radiators, but we don’t have a suitable scrum room/whiteboard and we’re prohibited from putting things up on the cubicle walls. Any advice on a technological solution.”

I responded that he had a deeper problem with the core lean principle of “respect for people” if the office furniture is more important than the people. Most people ignored my comment and actually answered the poor guy’s question. Use a wiki, cardmeeting.com, whatever. Nice, polite, helpful comments, totally missing the point of this guy’s problem.

But I’ve been thinking about that, and I wondered what I was prohibited from doing at my current place of employment. Here’s what I came up with (in no particular order).

Harassment
Assault
Theft
Vandalism
Indecent Exposure

Notice anything in common on that list? Those are all things that are prohibited by law in our free society.

I talk about “values” a lot, and how you can look at intellectual frameworks such as Lean and Agile as pre-packaged sets of values. I don’t think that any of them are definitive, and different groups need to come up with the values that matter to them.

So now, on the eve of the anniversary of the founding of this great nation (and trust me, it’s hard to be very patriotic right now, with the Scooter Libby thing and all) I’m thinking that an important value for companies/collaborative teams…. Liberty.

This is similar to Lean Software’s “Respect for people/Empower the team” value, but I think it’s more than that. People should only be prohibited from doing what harms other people or destroys property. Think John Stuart Mill’s “harm principle”.

And no, tacking up a chart on a cubicle wall doesn’t count as vandalism.

The oft-quoted “the customer is always right” is just plain wrong. If they were always right about everything, they wouldn’t need to bring in consultants with specialized skills, would they? Also, what if you have two customers, and they each thinks that the other customer is wrong? Instant Paradox!

I think instead that you should aspire to love the customer. Really. Anyone who has been married knows that it’s possible to still love someone even if you think they are wrong. Love, like software development, only works if there’s mutual respect. Even if you’re one of the best developers in the world, if you have the (all too common among coders) arrogant notion that everyone in sales and marketing are “stupid” or “dysfunctional”, you aren’t going to have successful projects.

Sometimes, things might happen that cause you fall out of love with a customer/client. Then it’s time to move on. Do the whole “It’s not you, it’s me” thing.An e-mail exchange with a truly dysfunctional customer is paraphrased below.

Me: “I’m sorry, I’m going to have to cancel our scheduled meeting, something came up. Can we meet tomorrow.”

Client: “This is unacceptable! You can’t cancel a meeting with me.”

Me: “Um… I can and I will cancel meetings when I need to. Something urgent came up. We can meet later this afternoon or tomorrow.”

Client: “This is unacceptable! You can’t talk to me that way! I’m going to shut off your access to the staging system so you can’t deploy your code anymore!”

Me: “Isn’t that kind of petty and vindictive?”

At that point, the client killed the project. It was a big loss for us. Or was it? It’s impossible to love the client in a relationship like that. And they sure as hell weren’t “right”

I recently was working on a project with a small group really skilled and talented guys. Everyone in the group (excluding myself for the sake of modesty) could safely be called brilliant.

We had a pretty important but straightforward task.  Something that any of us should have been able to complete on our own.Piece of cake, right? This should be a total success story.

We failed miserably. Of course.

Well, maybe we didn’t fail miserably, but we did get into a stalemate, the collaboration on the project was essentially killed, and there’s now one guy working on it by himself.
At the time, I was thinking of it as mostly an interpersonal issue. I like to say (and I believe) that “all software is interpersonal”.

I was thinking about it a little more yesterday, and I realized that we failed because we didn’t have any common understanding of shared values. One person in the group valued management mandate, and a fixed timeline. Another person in the group valued agile/lean/empirical processes and didn’t want to design the entire thing up front.  I valued egalitarianism and consensus-building, so I tried really really hard to negotiate and mediate between these two different values, trying to reach compromises, giving people a chance to save face, etc.

Which of those values should have been important to the project? I don’t know. My instincts lead toward the values that I try to bring to every project (the pre-packaged set of “agile” values, and my general anti-establishment bent). I can’t really say that if everyone thought like I did, the end result would have been as good as possible, although we wouldn’t have imploded in at least that way.

All of the things that I consider “qualities” or “best practices” such as strong cohesion, loose coupling, the ability to test things in isolation, those are really values. In collaborative projects, I’m not going to get anywhere unless I know that the other people on the project value them too.

I think that if more people were self-aware of the values they bring, and discussed them with a group to try to reach a set of “this is what we, as a team care about”, projects could go more smoothly.

It’s a lot better than one alternative, where you have one evangelist (often me) saying “Well Kent Beck says you’re supposed to…”

A few weeks ago, my son got a copy of Wii Play, a set of simple mini-games for the Nintendo Wii.

His favorite, by far, is the tank game, which is sort of an adaptation of the Atari 2600 classic. The innovation is that you point + shoot where you want the bullets to go with the Wii Remote.

Looking for a fun programming project, similar to the Asteroids project I did last year, I thought that I would do a tank game.  I thought it would be fun to involve Ethan, too.

So, I decided to treat him as a product owner and ask him about the game. I asked him about the “things” in the game and he identified the tanks, bullets, bombs, rockets, walls, etc. pretty well. I then asked him what a tank could do and he came up with move, shoot bullets, and drop bombs.

“So” I asked him. “do you know what part of speech these things are… tanks, bullets, walls”
“They are nouns”
“Right! I said, and now for the things that these nouns do, like move, shoot and drop?”
“Those are herbs!”

I’ll keep the blog updated with progress on the tank game.

There was a time when I loved using region tags in C#, it seemed like a great way to keep messy classes organized. I wasn’t a very good developer, and my classes were messy, but they were organized.

Now let’s think about what that means for a second. You can take a class that’s ugly and make it look better, not make it actually be any better, but it would look better. I’ve come around to thinking that ugly code should look ugly, so you are more inclined to fix it, and (most importantly) less inclined to make it ugly in the first place.

Also, regions are like comments, that is, they can lie. Very often I’v seen public methods in the region marked “Private Methods” and vice-versa. Automated refactoring tools actually make this problem worse. If you do an extract method refactoring on a huge public method using ReSharper, it will put the newly created (private, probably) method right beneath it. And I don’t really have a problem with it.  I generally try to keep to the guidance of fields/constructors/properties/public methods/private methods, but if a class is so big that I find things in it quickly, organizing/alphabetizing my methods isn’t the solution.

The only time I don’t remove region tags when I see them these days is if it’s a region of automatically-generated code from the IDE, and now that the new versions of Visual Studio use partial classes, I don’t see them much anymore.