Practical Software Development
Summary of the panelists' points of view on "Practical Software Development", and some of the key audience questions at the Feb. 16, 2010 meeting of the Eastern NC chapter of the IEEE Computer Society (surprise audience member: Dr. Frederick Brooks!)
This post was first published on the agile Teams WordPress blog on February 27, 2010. As of July 12, 2024, all agile Teams content has moved here to Agile Analytics and Beyond. Minor edits have been made to enhance accessibility and to credit the photos.
I had a great time participating in the "Practical Software Development" discussion at the Eastern NC IEEE Computer Society chapter meeting on Feb. 16 with
and Andy Hunt. Since I was one of the panelists, my notes are somewhat incomplete, but I've summarized some of the key questions from the audience and moderator John Baker, as well as the panelists' opening point-of-view statements.An unexpected highlight of the evening was our discovery that Dr. Frederick P. Brooks (yes, THAT Dr. Brooks, of Mythical Man-Month fame!) had honored us by joining the audience. His comment to me afterward on why he came: "You always need to keep learning."
(Event photos, including one with Dr. Brooks, are now included at the end of the post.)
My opening comments focused on the 21st century reality that almost all teams face the communication risks which are associated with globally distributed software development (GSD), even if no offshoring is involved: from distance, time zones, culture, and language barriers. Contrary to the myth of the solo programmer hacking out code in his/her cave, up to 70% of a developer's work can involve communications with other people. So being able to collaborate well under GSD-like circumstances matters in practice. Yet this is seldom recognized or addressed.
I did a quick 'show of hands' exercise with the audience to identify anyone who did NOT work with people who are from a different culture, have a different native language or educational background, sit more than 30 meters away, travel, telecommute, or work from home. The result? Only two people, one of them currently between jobs, didn't work under these team conditions.
Bob Galen identified some key patterns and anti-patterns he's noticed over the years:
Good patterns include collaboration, professionalism (including TDD, or test-driven development, and BDD, behavior-driven development); being 'language agnostic'; recognizing that "it depends"; allowing for variable scope and trusting the customer; and simplicity (using the Pareto or 80/20 rule).
Anti-patterns include poor listeners; non-continuous learners; laziness; and allowing oneself to be a victim of business pressures.
Bob commented further that he often sees so much emphasis on estimation that people "miss the actuals". He also observed that "planning is both everything and nothing": plans are useful as roadmaps and adaptive models, not as constraints.
My own experience in preparing for this panel session was a clear example of the principle that planning is invaluable even though plans 'seldom survive first contact'. I had prepared some slides in advance for my POV presentation. At the panel, none of us showed or used slides; we all talked extemporaneously based on reference sheets of notes. However, the time I spent preparing my plans (slides with notes pages) wasn't wasted. Doing so really helped me to clarify in my own mind what I thought were the most important points I wanted to make. Plus, a printout of my slides served as my 'talking point' notes, as well as on-hand paper for taking these notes on what everyone else said and what questions were asked by the audience. A PDF handout of the slides I 'used' will be available for download from the Agile Teams publications page.
Andy Hunt focused on what it means to be agile, suggested that an actual definition of agile was needed, offered one: "Agile development uses feedback to make constant adjustments in a highly collaborative environment." Then he queried, "When would you not want to do this?" He identified having an accessible, co-located customer as the biggest success factor, and commented that Scrum stand-ups are useful because they "help the team get out of their own way".
On the technical side, Andy cited a mantra inspired by Dijkstra's 1972 Turing lecture "The Humble Programmer": Always remind yourself "I am an idiot", and get another pair of eyes to look at your idiotic code, because you really do not know for sure what it will do. Andy also observed that you could replace S/360 with the name of a modern computing system in Brooks' classic book "The Mythical Man-Month", and find it still holds up today.
Favorite practices the panelists agreed on: version control, unit testing, and automation. (Andy characterized these as "hygiene, like brushing your teeth".)
Audience and moderator questions touched on the topics of:
Eliciting and considering non-functional, or performance, requirements. This is big on my lessons-learned list, based on my experience in software requirements and architecture. Customers often do not think to even mention these needs, but they are critical to delivering a product that people actually buy and use. Requirements in general are not mushrooms waiting to be gathered, they are more like truffles that an industrious pig must locate and dig up! Andy suggested that developers should learn interviewing techniques from journalists.
Whether reuse can ever work. None of the panelists has really seen it work in practice outside of a group, which I view as a matter of trust.
How to keep team members happy and reduce attrition. Money is important, but not all-important; good relationships with managers and a sense of teamness with peers matter a great deal. Best way to find out what kind of recognition or reward matters to them? My answer: Ask them.
Whether demonstrating working software at the end of an iteration really works well. Panelists' answers: yes - it's great for building trust with your customers; just find a way to do it, even if what you did during the sprint was more along the lines of infrastructure or 'plumbing' (Bob's term) than executable code.
We all agreed on the importance of having good people, although we didn't completely agree on the criticality of having the most-skilled top 1% of people in order to be successful. Most companies will need to find a way to be successful with the people who fall in the middle of the bell curve, not just those few who are on the high end of the long tail.
This is where I think teams matter most: jelled teams of good people can produce and succeed where teams of geniuses who don't work together well can clash and fail. (American baseball offers a good example of this - All-Star games usually aren't nearly as good as the World Series.)
Some key points we agreed on:
The phrase"agility vs. discipline" is misleading because being agile requires significant discipline, and being more agile requires more discipline.
Management and leadership are distinct (my view: good managers lead people and manage projects).
Over the next 10, 20, or 50 years, the world of software will keep changing at a lightning pace; being willing to keep learning is essential.
What a great way to kick off the local Computer Society chapter's 2010 year! Kudos to leader John Baker for organizing and moderating some enjoyable discussions! (See John's blog post and tweet, and Andy's tweet, about meeting Dr. Brooks). I'm looking forward to the next chapter meeting! (See the LinkedIn group for more details.)
Event Photos
