Red Squirrel Reflections Dave Hoover explores the psychology of software development

"Making partners with customers means they become more likely to understand technical constraints." --Steve McConnell, p. 238, Rapid Development

Steve is singing the praises of customer-oriented practices, yet another apparent overlap with XP. The above quote forced me to stop reading and start writing: it concisely describes my experiences with The Planning Game.

These experiences are fresh in my mind because I facilitated a Planning Game (release planning, not iteration planning) this week. It is my second such experience and boy is it easier the second time around! In my first Planning Game experience, after we had estimated a few stories, the customer interjected, "I think we may have more than 3 months of work here" (1/16/03). In our collaborations this week, our new customer surprised us by making the exact same comment.

If you're a developer who is accustomed to repeatedly defending and reasserting your estimates, hearing a comment like this from a customer is priceless.

We keep the customer with us as we estimate our user stories. While some people were nervous about wasting the customer's time listening to technical discussions, I insisted on the customer's attendance. Inevitably, as we estimate, we need clarifications that only the customer should provide. And equally importantly, the customer catches a glimpse of the amount of work that goes into developing their system. This inevitably leads to a more appreciative customer, and a stronger partnership.

"Good relations with customers improve development speed. If you have a cooperative rather than antagonistic relationship and good communications with your customer, you eliminate a significant source of inefficiency and major development errors." --Steve McConnell, p. 236, Rapid Development

Posted by Dave [Link]

After reading the Cutter Consortium's Agile Project Management Executive Report, Building the Emotionally Intelligent Agile Manager, I was excited by the notion of EI (emotional intelligence) and the role it plays in the life of the agile manager...

"Agile managers' hallmark is adaptability and flexibility, but this flexibility must be based on accurate information. Given the close interactions within the development team (e.g., pair programming) and the frequent interaction with stakeholders, much of the critical data regarding a project is interpersonal or emotional in nature."

And then I read Esther's Qualifications for management and my excitement continued...

"If you want to be a great manager, learn as much as you can about working with people. Make it your major field of study."

Yet, despite these seemingly clear indications to me that my background and passions are leading me toward some form of management, the thought of actually being a manager is not attractive to me at all. This was hammered home during a zeroth draft exercise this afternoon. After some free association, I wrote the question, "What do I want to be when I grow up?" My answers included author, consultant, teammate, architect, facilitator, programmer, and coach, but not manager.

I believe my apprehension about management is rooted in the fear of loss. I find joy in solving difficult technical problems, in collaborating successfully as a team, in resolving and learning from conflict, and in creating learning opportunities for teams. My notion of manager seems to exclude what brings me joy and therefore the idea of management is unattractive.

I need to find some management examples that challenge my notion of manager. Intellectually, I know that many of the things that bring me joy fit nicely into the manger's job description, but my real-world examples of managers seem to have jaded me.

I want to keep a firm grasp on technology while collaborating with and empowering my teammates. David Socha took the words right out of my mouth...The human side of software fulfills me; the software side fascinates me. My brain tells me that a good manager is in a pivotal position to positively influence a team, but my gut keeps telling me to stay in the trenches.

Posted by Dave [Link]

"...the key is to know in advance what we're building so we're confident it will meet our needs, and so we can test it." page 318, William Grosso, Java RMI

This quote caught my eye this morning as I was reading on the train. William has made it clear throughout the book that he is a fan of XP and unit testing. He even devotes an entire chapter to developing a homegrown multi-threaded test fixture for remote servers. It's good stuff.

And yet, a quote like the above doesn't smack extreme to me. I found myself immediately rewriting the sentence in the margin...

"The key is to test in advance what we're building so we're confident it will meet our needs."

While I am happily surprised to find numerous XP references in a purely technical book, I wonder how long it will take for technical authors, editors, and publishers to take the step off the cliff into the world of the extreme. I wonder how much longer it will be until test-driven development is popular enough that it will be advocated in literature that is not explicitly focused on testing, development processes, or agile development? I suppose it will happen when TDD is no longer viewed as extreme.

Posted by Dave [Link]

A 1999 article by Justin Kruger and David Dunning in the Journal of Personality and Social Psychology studied the effects of competence on self-assessment.

Kruger and Dunning found that incompetent people suffer from a dual burden: not only are they incompetent, their incompetence blinds them to their own incompetence. The experiments found that bottom quartile performers consistently estimated themselves as performing above average.

The article reported significant findings for top quartile performers as well. Top performers consistently estimated themselves as performing lower (compared to peers) than their actual performance. They fell prey to the false-consensus effect, in which people assume their peers are as competent as they are.

The researchers found that training combined with peer collaboration allowed both competent and incompetent people to improve the accuracy of their self-assessments.

What are the implications for software development? Surely there is a significant percentage of incompetent software developers out there in the world. Kruger and Dunning's findings suggest that the majority of these developers believe that they are above average...

Uh-oh. I believe I'm above average. How can I be sure that I am not Unskilled and Unaware of It? Unlike the tests administered by Kruger and Dunning, software development is far from objective. We can successfully solve a business problem and write brittle, bloated software at the same time. It happens every day all over the world. So if I am unskilled, how do I become More Aware of It?

The best way I know how to protect myself from being Unskilled and Unaware of It is to continually train myself and to surround myself with people I regard as competent. I want to be around people who will challenge my ideas, people strong enough to disagree with me. These are the types of people who will inspire me to learn rather than lead me toward a false sense of competence.

"Everybody on an XP team should feel like an idiot regularly." --Extreme Programming Applied: Playing to Win, p. 62, Ken Auer and Roy Miller

Another tell-tale sign of becoming More Aware of It is a universal learning phenomenon: the more I learn, the more I understand how much more I need to learn. As long as I regularly experience this phenomenon, I know I'm headed in the right direction.

"If we can get introduced to our ignorance, isn't that something worth celebrating?" --The New Peoplemaking, p. 220, Virginia Satir

Posted by Dave [Link]

I have felt compelled recently to learn more about network programming with Java. The guys I have lunch with every week recommended a couple O'Reilly books, particularly Java Network Programming. As I walked back from lunch, I stopped by Borders to pick up the book they recommended.

I looked high and low but couldn't find the book. And then a familiar TLA jumped out at me, O'Reilly's Java RMI. I pulled the book off the shelf and laughed out loud. The animal on the cover was a red squirrel.

It's turned out to be one of the best technical books I've read. It references XP, refactoring, JUnit, and has been easy to digest thus far.

Posted by Dave [Link]

[Archive Index] [Main Index]

Powered by Greymatter