Monthly Wrap-up - December 2007
First, I’d like to wish everyone a belated Happy New Year. I’m starting to get back in to the swing of things, and I’m looking to publish as frequently as I was before the months of November and December consumed my time with other positive diversions. In some ways I believe the slower pace was actually positive as the readers began discovering the earlier articles that were published, and as I’ve been saying, the most practical and readily usable article published was “An Objective Method for Navigating Your Project Successfully.” That article was the third most read article for the month of December. The top five articles for the month of December are as follows:
- Software Metrics: Making the Case
- Outsourcing Debate - Two Guys Talk it Out
- An Objective Method For Navigating Your Project Successfully
- Why Software Process Adoption Fails
- Believe Defect Free Code is Possible
The five most read articles of 2007 are as follows:
- Why Software Process Adoption Fails
- No Pain, No Gain
- Reflection: Unrealistic Schedules
- Part 1: How to Manage an Unrealistic Schedule
- Danger Agile Practices at Work
We often focus a lot of attention on process and the technical aspects of our work to improve software management. While those aspects are important, there is less written about the people and cultural aspects that impede our productivity and success. In January, I started writing about those aspects of the work that we need to address. Improving process and the technical aspects will only get us so far in improving software practices. To realize even further gains, we need to address the behaviors and attitudes that also impact the team’s ability to perform at peak. Please, share your experiences and thoughts. I’d like to learn of other perspectives on the subject.
It’s been a good six months since I’ve started this blog, and the readership continues to grow every month. Thanks for your support, and I hope to continue to publish articles on software development that you will find interesting and valuable to your work.
January 26th, 2008 at5:50 am
I think you’re onto something when you say behavior needs to be addressed to harness team productivity. More efforts in training junior members of teams needs to be focused on analysis and communication. As a philosophy professor who once critiqued my written work said “If you made mistakes taking a math exam i can see you can’t add. If you make mistakes in your grammar and sentence structures, what other evidence do I have that you can think?”
If you can get someone who can frame a problem that the customer of business unit can immediately recognize as a correct solution in their terms you have a better chance at solution accuracy. This is hard, as many developers speak in different terms, and some are incomplete analogies that do not address issues at hand. Too many times I have heard things like “Oh, we’ll handle that with a facade pattern” as they are not expending the mental effort to understand what other underlying issues need to be addressed.