The “do do” Guy

Dave Thomas graciously accepted my invitation to a book discussion of The Pragmatic Programmer today. I hope we at least provided some entertainment for him. At one point there was a discussion about whether a peculiar behavior was truly a bug. Dave asked “and the business people say…” with the same cadence as the Lou Reed song, “Walk on the Wild Side”. Mike Schaefer recognized this and immediately answered with “doo do doo, doo, doot do doo…” Everyone in the room nearly doubled over in laughter. I think Dave will forever remember him as “the do do guy” :-)

potential differences [/fun] permalink

The Ideal Programmer

Bruce Eckel has some great stuff about programming. I suppose I think it’s great because it mirrors some similar thoughts I’ve had for a while. It’s nice to be validated by someone well known and respected :-)

Programming is about communication between humans.

Programming is not about racing to throw together a solution. It’s about changeable systems.

If you’re a college student who expects furniture to receive abuse, only expects it to last only a few years, needs it right now, and has limited income, then that particle board bookshelf is probably your best bet. However, it also makes sense to you if you know next to nothing about furniture, you’re caught up by the pretty pictures of it in a catalog, you’re cheap, and you’re not prone to thinking in the long term (oh, and you’re an executive at a large company).

Bruce Eckel is thinking of that second case by saying that programming is not a sprint to finish in that the “executive” needs an eduction, but I think that sometimes the “college student” case applies, when a quick solution thrown together best fits the situation. That being said, I’d personally rather be crafting than hacking (in the bad sense), but we need to recognize that it’s not always appropriate. Programming in the real world is not always craftsmanship.

The “Love It or Leave It” section reminds me of an experiment I’ve been running in the self-selecting nature of programmers of like mind being drawn together. I guess the results are conclusive enough that I can let the cat out of the bag now. In my first weblogs.java.net post I talked about people needing to take some pride in their craft and keep themselves informed of what going on, even for things that aren’t directly relevant to their task at hand. In it I referenced an incident here at work where some people could use a bit more broad of an exposure to Java technologies. That weblog is much higher profile than mine here, so I was wondering if any of those people would comment to me about it. They haven’t.

potential differences [/development] permalink

Distinctions of an Agile Developer

Warning: risk of stereotypes and psychobabble ahead

I’ve been experiencing resistance to Agile methods lately and I’m trying to figure out why. A few other bloggers have begun discussing this and I hope I can add something useful to the conversation. Brian Marick touches on several issues relating personality type/thinking style to testers and Agile methods in general. He references Bret Pettichord’s “Testers and Developers Think Differently” which initially made me wonder if I’d fit better as a tester than as a developer. Brian also ties it in with Alistair Cockburn’s investigation of what sort of personality a business coach needs.

Now, I’ve long been fascinated with the Myers-Briggs style of personality assessments since first being exposed in college (interestingly, it was a Physics class, not Psychology). I’m INTJ with INTP leanings (now you can all pigeonhole me :-) This personality type (or really the more general ‘NT’ — the middle two initials) is a small percentage of the general community, but a large percentage of the software development community, so I believe that the differences between Agile and un-Agile (for lack of a better, non-perjorative term) developers must be a second order effect.

These ‘NT’ (Rational) types learn to trust in their intelligence, often basing their own self-image around it, which is usually compounded by their awkwardness in social situations and the corresponding belittling during adolescence. Though we don’t like to admit it, we ‘rationals’ do carry emotional baggage as Chrisitan Sepulveda explores. As a friend, Paul Holser, put it “we all want to be Spock, but are really McCoy underneath all that.”

Agile development requires a large amount of humility. We have to trust that practices such as TDD (Test Driven Development) might lead to better software than what we could develop purely via our own creative processes. And if it doesn’t then the problem might be us rather than the method. To someone who’s self-image is largely centered on their own intelligence, this hits mighty close to home and evokes emotional defenses. Ironic in such rationally centered people. My working model is that it takes maturity to reach humility, but I’m not particularly satisfied with that because I can envision the argument “you don’t agree with me because you’re immature and I’m not, so nyah.” I also wonder if there’s a faith aspect too because it can cause one to re-center their self image on something beyond themself thereby avoiding that emotional threat, but that’s not something we ‘rationals’ talk about much, so it’s tough to tell.

One of the keys of the Agile Manifesto is valuing “individuals and interactions over processes and tools”. It’s people oriented. That’s what has been leading me down this path of trying to understand people and their resistance. The manifesto makes it sound so common-sensical, so adaptable, and so applicable in all circumstances, but I’m starting to discover that valuing individuals includes knowing when to stop pushing. So at what point to I stop trying to convince people that Agile development would improve their situation and simply look for a new situation for myself? Is Agile Methodology just a “birds of a feather flock together” sort of mindset? Anybody know of some healthy flocks?

potential differences [/development] permalink

A New Name for TDD

Brian Marick writes Things Agilists Want to be True. It’s a great start, but I have the gut feeling there’s more to it. I can’t point to any specifics right now, but the synergy is quite interesting. I just purchased the Scrum book he refers to last week, and I also just told a group of testers this morning that I predict that TDD will be renamed within the next year. I don’t know how many times I’ve had to explain to people that the validation aspect of TDD is secondary to the way it drives the design of the code (including this morning right after reading Brian’s blog).

So maybe it’s time to start brainstorming other terms. I’ve had a few come to mind:

• Usage Driven Development
• Client Driven Development
• Outside-In Development

I’m also going to be observing the team dynamics as our department takes on more of an agile philosphy. Without much authority behind me this morning, I was trying to explain to the testers that developers are encroaching on their ‘territory’, and they should be responding in kind by expanding their test automation and styles of testing.

potential differences [/development] permalink