Red Squirrel Reflections Dave Hoover explores the psychology of software development

"Good programmers are a little bit lazy: they sit back and wait for an insight rather than rushing forward with their first idea. That must, of course, be balanced with the initiative to code at the proper time. The real skill, though, is knowing the proper time. That judgment comes only with the experience of solving problems and reflecting on their solutions." --Programming Pearls, Jon Bentley

One of the lasting insights that I gleaned from Ron's Extreme Programming Adventures in C# was the importance of timing and rhythm in programming. "Pairing" with Ron revealed to me how integral these concepts are to his craft. Many of his micro-decisions were based on his sense of timing.

The rhythm of Ron's programming reminded me of my experiences with martial arts. I spent three years studying Kenpo. I remember watching advanced students and being impressed with their timing. They had the ability to control not only where their strikes and blocks would land, but also when. There is an optimal moment for each movement that maximizes effectiveness. I have a tendency, in martial arts and in programming, to unleash a flurry that can overcome most ordinary opponents. But when I am facing a more advanced opponent, an uncontrolled flurry leaves me tired, frustrated, and unsuccessful. I know where to focus my power, but I often fail to pay attention to when I should focus and when I should hold back.

I have noticed since finishing Ron's book that I have been more attentive to my timing. I find myself taking more breaks. It has helped keep my mind fresh and focused. Are you aware of your programming rhythm?

Posted by Dave [Link]

Last week I discovered that Ken Schwaber has spent time as a volunteer marriage counselor. I emailed him, curious to know if/how his experiences had shaped his approach to software development. One of his insights caught my eye...

"People only change when something is dramatically wrong, forcing them to reassess. Otherwise, dysfunctionality is preferrable."

This reminded me of "raising the bottom," a therapeutic technique that is used with someone who is not going to change until he hits "rock bottom." The sooner he can realize that something is dramatically wrong, the sooner he will improve. "Raising the bottom" involves coordinating a "tough love" support system that facilitates the person hitting rock bottom and then supports him as he reassesses his situation.

I'm wondering how well this idea might map to software development teams. I think consultants can sometimes become enablers of dysfunction. Rather than helping a team feel their problems, we too often treat symptoms or overcompensate, delaying the priceless feedback that hitting "rock bottom" provides. How can we as consultants "raise the bottom" for a dysfunctional team without destroying the team in the process? Any ideas? Any experiences to share?

Posted by Dave [Link]

I am reading two excellent books right now: Extreme Programming Adventures in C# and Domain-Driven Design. One aspect of both books that I am particularly enjoying is language...

Ron speaks of objects as having wants, needs, and voices. The language he uses personifies them. For instance, "the test is telling me things about how the object should work" and "the InputCommand is trying to grow up into some more advanced kind of object." His language reveals a bit about how Ron develops software: with a vivid imagination.

Eric places explicit emphasis on developing a shared language amongst domain experts and software developers. This idea excites me because (at least in my head) its effectiveness is reinforced by what I know of The Social Construction of Reality.

Posted by Dave [Link]

Here is a paper on power and value conflicts in and around agile teams. I have been fiddling around with it for the last couple months. I'm not thrilled with it's current condition, but at least it gave me an excuse to reference Weick and Roberts' collective mind study. I've been waiting for a year to apply their notion of collective mind to agile teams. I have only lightly scratched the surface with this article.

If anyone reads it, I would be interested in your feedback.

Posted by Dave [Link]

I'm having too much fun with my new Lego Mindstorms tonight. I just watched my first robot (it's the simplest thing that could possibly move) take off down the hall after my brother (2000 miles away) hit the submit button on a Perl CGI. Thank you LeJos, thank you socket, and thank you socket!

Posted by Dave [Link]

Bill Caputo posted a link to this article about situated software ... an emerging software niche that serves small communities of users. Very interesting article.

Also: My Lego Mindstorms are arriving today. It is my 30th birthday present ... my preciouss ...

Posted by Dave [Link]

[Archive Index] [Main Index]

Powered by Greymatter