Monthly Wrap-up: February 2008
In February many of the older articles continued to have heavy readership. I find it interesting to see how the articles of interest evolve over time. Some of the older articles are the most popular articles for the month when not too long ago it was always the latest articles published that would have the largest readership for the month. The top 10 articles for the month of February are as follows:
- “Reflection Unrealistic Schedules“
- “No Pain, No Gain“
- “Refactoring Isn’t A Design Methodology“
- “Danger Agile Practices at Work“
- “Agile Isn’t a Process“
- “An Objective Method for Navigating Your Project“
- “Part 1: How to Manage an Unrealistic Schedule“
- “Outsourcing Debate - Two Guys Talk it Out“
- “Monthly Wrap-up - January“
- “Certifications, Who Needs Them?“
The top 10 countries visiting “You Want It When?” for the month of February are as follows:
- United States
- Canada
- Australia
- Great Britain
- Netherlands
- Japan
- Germany
- China
- Thailand
- Hong Kong
In February the focus was on critiquing the Agile Methodologies. I believe the Agile proponents have been correct in attacking some of the traditional software development practices. I’m sure we share a common disdain for many of the process-for-process sake requirements of traditional practitioners. I think in many cases the engineers working in traditional shops find the practices stifling as well, but they are often powerless to change it, so everyone goes along to get along; apathy essentially sets in. The Agile proponents need to be concerned about similar behaviors on their projects. When dogma sets in, momentum often prevents the practices that require change from changing. A good process is one that changes. For process to endure in corporate settings, it must change - even Agile.
It’s interesting to read some of the articles from Agile practitioners. They’ve invented a lot of good jargon to describe what traditional practitioners have been doing for many years. Refactoring is one of them. There’s little new here except that the Agile practitioners have given it a name. Traditional practitioners have always redesigned and recoded their applications where and when appropriate, but there is one distinction between the traditional camp and the Agile camp: the Agile methodologies make refactoring inevitable, while the traditional practices attempted to avoid this with more investment in up front analysis and design. There should be goals when deciding to refactor. The goals that I target are to deliver faster and/or to improve the quality (less defects). It’s always to serve the business needs, never elegance–for–elegance sake.
In May, I will be presenting at the PSQT Conference in Las Vegas. The topic of my presentation is “Test Driven Quality.” If any of you happen to be attending the conference, please find a way to say hi. I’d value the opportunity to meet some of my readers.
Please keep reading, tell your friends about “You Want it When?”, and Email me if would at “bill(at)yuwantitwhen(dot)com” to share your thoughts, critical or positive commentary or even topics that you would like me to cover in future articles.
