Red Squirrel Reflections Dave Hoover explores the psychology of software development

I'm finishing up my first week at ThoughtWorks. I couldn't be happier. I've spent the last three days with my new laptop teaching myself C# on Visual Studio with NUnit. And when I say teaching myself, I mean reading and coding for a while, and then harrassing Mike Two for a while. Mike is one of the authors of NUnit and is sitting about 4 feet away from me. I like working at ThoughtWorks...they're paying me to do something I would pay to do.

Posted by Dave [Link]

Brian almost blogged about how to shift people's ontologies, which, he claimed were malleable until he thought better of it. I think it was a good move to veer off from that argument. While people's ontologies can be shaped, their ontologies are not often easily changed, certainly not as easily as software...

"By saying that people's ontologies are malleable, I'm being as optimistic about people as I am about software."

Brian's statement speaks volumes about why I find software development to be significantly easier than family therapy. While I am a die-hard optimist about both people and software, my experiences have taught me that software is generally more malleable than people.

Posted by Dave [Link]

Note: I edited this entry out of an article I'm writing because it was no longer needed. I'm finding it hard to let go of, so I posted it here. It's a brief description of how the different software development roles are impacted by the flattened hierarchies of agile software development.

"On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader... The structure of the team is a network, not a hierarchy." Peopleware: Productive Projects and Teams, 2nd ed., p. 155, Tom DeMarco and Timothy Lister

Steep hierarchical structures tend to trap knowledge and authority in the hands of the select few. Agile teams have relatively flat hierarchies compared with their traditional counterparts. What does this mean for each of the traditional software development roles?

Architects

The principles of agile software development pull architects from their quiet cathedrals and invite them into the bazaar of developers. Architects find themselves in the trenches, literally shoulder-to-shoulder with developers, continually facilitating evolutionary design while maintaining conceptual integrity within the system.

Developers

Agile developers find themselves with more responsibilities than their traditional counterparts. They are responsible for effectively communicating with machines and humans. They are responsible for living up to their own estimates. Most unnervingly, they are responsible for collaborating with their teammates to continually improve the design of the system.

Managers

Managers of agile teams can find themselves caught between the values of agility and the values of the larger organization. While they remain under pressure to deliver better software faster and cheaper, they can no longer dictate fixed-scope, fixed-time schedules upon their teams. Instead, managers are informed daily of their teams’ progress, giving managers increasingly accurate estimates for delivery.

Customers

Agile teams’ relationships with business sponsors have fundamentally changed from competitive to collaborative. In many cases, business sponsors weren’t even considered a part of the team prior to the introduction of the agile principles. Business sponsors now find themselves attending daily status meetings, continually refining (and redefining) user stories, and test-driving early releases of their systems. Customers are a single voice speaking from within the eye of the hurricane that is this agile team. Their ongoing requests drive the entire development life cycle.

Posted by Dave [Link]

My job search has ended. In two weeks, I will be just another ThoughtWorker. I'm pumped.

Posted by Dave [Link]

I am currently working through the Poppendiecks' excellent book and found a few ideas that made me think back to an earlier entry on metaphors in software development.

"Perhaps some of the reluctance to use approaches from product development comes from unfortunate uses of metaphors in the past. Software development has tried to model its practices after manufacturing and civil engineering, with decidedly mixed results. This has been due in part to a naive understanding of the true nature of these disciplines and a failure to recognize the limits of the metaphor." (xxii)

"Principles are guiding ideas and insights about a discipline, while practices are what you actually do to carry out principles. ... We believe that there is no such thing as a 'best' practice; practices must take context into account. In fact, the problems that arise when applying metaphors from other disciplines to software development are often the result of trying to transfer the practices rather than the principles of the other discipline." (xxiv)

Today I was skimming some books in a nearby Borders during lunch. I picked up The Art of Software Architecture and read an interesting sidebar on metaphors. Albin disparaged the common assumption that software architects should resemble building architects. To paraphrase Albin, if designing, constructing, and maintaining buildings was like software development, building architects would be getting requests to have entire floors removed or added and additional structures appended onto the building.

The sidebar went on to note that urban engineering might be a better metaphor for software development, where engineers and planners receive requests for new housing developments, reducing traffic congestion, and connecting adjacent communities. Like any metaphor, Albin notes, this one also has limitations, but it certainly feels more applicable to me.

In the short term, though, the urban engineering metaphor does almost nothing for me because I don't know jack squat about urban engineering. Therefore, my application of this metaphor would almost certainly be naive. I believe this is what makes the Poppendiecks' book so effective. They have expertise in the domains of lean development and software development. Thus, Lean Software Development.

The Poppendiecks' book encourages me to continue to explore the potential metaphors and shared principles between the two domains in which I have expertise: family therapy and software development.

Posted by Dave [Link]

[Archive Index] [Main Index]

Powered by Greymatter