Although Agile testing techniques have helped us to create higher quality software, many software developers still spend significant amounts of time debugging their own or other people’s software. Some of the most difficult software to debug is code that has “evolved” over time in a mostly arbitrary way. The software is not well structured or organized and the rationale for much of the behavior is not clear and often forgotten even by the original developers. If the original developers still develop and maintain the code, they may be comfortable with the numerous bugs due to familiarity with the software and their personal connection to it. They may even resist any suggestion that the software could be refactored or redesigned to be much more effective and relatively bug free.
It’s easy for an Agilista to criticize this type of situation, especially if we must interact with the buggy software or otherwise depend on it in some way. However, don’t we have the same attitude towards our own buggy “wetware”, the software of our mind? Continue Reading »
Have you ever worked with someone who is proud of how well they fix problems or bugs… that they created in the first place! I’ve seen people who are quite successful with this strategy although it never ceases to amaze me. Unfortunately, I see agile practitioners do the same thing in the domain of planning support tools by comparing collaboration-oriented planning tools with traditional unshared spreadsheets.
The party line in XP/Agile is that note cards are the best planning tool. The only disagreement I have with this perspective is that cards are the best tool, independent of context. Cards are good and even best in some contexts. I’ve used cards and they worked well. However, I prefer computer-based collaboration tools to augment face-to-face communication and, in my experience, it generally works better than cards for the full scope of planning-related activities (plan generation, tracking, replanning). Continue Reading »
Some my earlier comments have been described as a “backlash” against agile software development. It’s definitely not a backlash against agile software development techniques or goals, but more about the rigid attitudes I see in some branches of the agile community (mostly from a relatively small, but very vocal, group of XP evangelists). This rigidity of agile perspectives is quite ironic.
However, it’s easy to oversimplify an analysis of the situation. There are many people involved with the agile movement with many different motivations. There are people who are primarily looking for ways to do their job better and enjoy the work more. And even within that category there are people who are constantly working to improve and others who just want to be told what to do. Some of the people have extensive prior experience with successful agile-like (but not officially XP/Agile) projects. Others are newcomers. They are developers dillusioned with inefficient organization and personal behaviors and who are looking for alternatives. My guess is the silent majority of the 8000 members of the Yahoo Extreme Programming mailing list are in these categories.
Then there are the coaches, consultants, and authors. Continue Reading »
On the topic of definitions of agile development, I saw an article from Scott Ambler that defined an agility quotient. I believe the most important agile factor is the focus on delivering value. Many of the other agile factors mentioned by Ambler are implied (but not necessarily required) by this one. For example, a team can’t deliver value if they don’t focus on creating working systems. However, they could deliver value without being “test infected”. The ability to respond to changing requirements would lead most teams to focus on regression testing but it wouldn’t require automated tests or TDD techniques. I’ve personally seen teams who were successful at delivering value early and often with frequently changing requirements and without many automated regression tests.
There seems to have been a recent increase in discussion around the definition of “agility” in a software development context. For example Brad Appleton has offered a definition of business agility. Business agility and software development agility seem to me like two different, although related, concepts but the post and comments are interesting. Brad also blogged elsewhere on nutshell definitions of agile development where he included some related definitions from members of the Yahoo extreme programming group and a few other sources.
Today, I saw a blog post comparing software development styles to martial arts and philosophical schools. It was interesting to me because I’ve also been thinking of similarities between Jeet Kune Do and my own philosophy on software development.
Continue Reading »
