From the Mailbox: Bad Agile Engineering?
November 21st, 2006
Filed under Agile
A question from my email archives:
“I’ve been researching Agile. It seems to me that Agile projects tolerate bad engineering, and then testing has to deal with the consequences. Care to comment?”
Ah, yes. The old “Agile is a license to hack” misconception.
Let’s flip the question around. The writer asked about bad engineering in Agile. But shoddy coding practices are everywhere.
One example: on traditional projects, “unit testing” tends to be whatever the developer has the time and inclination to do. It usually involves some combination of manually poking around and stepping through the code with a debugger. When I ask traditional teams about their unit testing practices, my questions are often met with eye rolling, laughter, or deep sighs of despair. Given the free availability of the xUnit family of unit testing harnesses for a wide variety of modern languages (Java, C#, etc.), there is no excuse for any team working in one of these languages to do manual unit testing. None. And yet poor unit testing practices persist throughout the software industry, particularly on teams following traditional practices.
But Agile teams typically do use the xUnit frameworks because they value the fast feedback. Test Driven Development is even more rigorous, and every XP team I have seen does it. They might not pair, but they do TDD.
It seems to me that this isn’t really a question of traditional v. Agile. It’s just a fact of life. Business realities dictate that there will always be situations in which development teams end up taking shortcuts. Agile doesn’t prevent shortcuts, it just makes them visible. On traditional projects, I find stakeholders often aren’t even aware of the shortcuts the developers are taking to meet the schedule demands. But on Agile projects, stakeholders can see that the build is red or hear about tradeoffs developers are making in the daily meeting.
As for the testers, it is true that they will be affected if the programmers don’t consider testability or if the code is too buggy to operate. But having worked on both traditional, phased projects and Agile projects, I can testify that I had a much easier time testing on the Agile projects. The lines of communication were shorter (given that the programmers sat next to me) and the software was always ready to test. I spent much less time spinning my wheels, and more time doing things that added value to the project: testing the software and sharing what I learned with stakeholders.
4 Comments
Leave a Comment
Because of the rise in blog-spam, I've turned on comment moderation. If it takes a while before your comment appears, I hope you understand.
Moderation Policy: I approve substantive comments. I reject ads. And if I don't know whether it's substantive or advertising, it sits in my moderation queue until I get sick of looking at it, at which point I reject it, kind of like the questionable meatloaf in the fridge. But please be assured that I think long and hard before clicking that reject link. I really am grateful for every comment any human takes the time to make. (Spambots, not so much. But if you're reading this, you're probably human.) So please contribute to the conversation...
Nov 22, 2006
9:43 am
One way I’ve heard this put is that there are 3 development practices– engineering if you will– that reinforce each other:
test driven development (TDD)
pair programming
continuous integration
If any of these practices exist in the absence of *all* of the other practices, there is a high risk of something going haywire in the development process.
I saw this on a project once myself. I automated a build system so that instead of two builds per week, we could make six builds per day. All I accomplished was to send the message “the code sucks” thirty times per week instead of twice.
Scenarios involving the other practices I leave to your imagination.
Nov 22, 2006
10:10 am
Chris said, ‘All I accomplished was to send the message “the code sucks” thirty times per week instead of twice.’
I’m curious: did seeing the message “the code sucks” thirty times a week instead of twice have any effect on the behavior of the team? Sometimes it takes repetition for feedback to sink in. Perhaps this has something to do with pain thresholds: hearing “the build broke” twice a week is less painful than hearing it thirty times a week. Twice a week is ignorable. Thirty times a week is sufficiently painful to prompt someone to do something about it.
On the other hand, I know of organizations that booted out Agile specifically because visibility increased. Hearing “the code sucks” with greater frequency is painful. One remedy for the pain is to fix the underlying problems that cause the build to break. But that requires change. Another way to mitigate the pain is to throw out the automated build system so we don’t have to hear “the code sucks” quite so often.
I’m sure you can imagine which remedy I prefer.
Nov 22, 2006
10:58 am
Chris said, ‘All I accomplished was to send the message “the code sucks” thirty times per week instead of twice.’
Elisabeth said, ‘Did seeing the message “the code sucks” thirty times a week instead of twice have any effect on the behavior of the team?’
Did they even talk about it? I’m coming to the conclusion that retrospectives are the best tool available to help a team change their practices for the better.
Nov 22, 2006
2:40 pm
In a nutshell, I left the company just before they started outsourcing their development.
All kinds of good stories about this group. At one point I became alarmed about one project because of all of the “90% done” estimates I was hearing. So I made a Big Visible Chart of “things known to be working” (green), “things known to be broken” (red), and “things about which we have no information” (yellow). Although no one disagreed with my analysis, after about two weeks of seeing a few green items in a sea of yellow and red, I was asked to erase the chart from the board.
It was a fairly dysfunctional group.