Agile Methods Need Agile Developers
- Taking Responsibility
- Applying Feedback
- Pragmatic Environment
- Coding Techniques
- Sign Your Work
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Agile methodologies are changing the face of software development. Suddenly, everyone on the team is a critical part of the solution. Every programmer has wide-ranging responsibilities and must make decisions that affect the outcome of the project. Instead of trudging along like an anonymous foot soldier on a death march project, we've got to parachute into the drop zone with what we can carry on our backs. We've changed the paradigm: Infantry have become commandos.
Unfortunately, this isn't always an easy transition. It takes time and experience to get used to the freedoms and responsibilities. This experience is always hard won: You have to make mistakes to learn, and sometimes that can be painful—not to mention expensive. Having made most of these errors ourselves at various points in our careers, we decided to try to spare others from the same pain by capturing what we'd learned. We call the result pragmatic programming.
In this article, we'll look at a few of the basic aspects of pragmatic programming: taking responsibility, applying feedback, creating a pragmatic environment, and basic coding philosophy. Pragmatic programming is about doing things that work, regardless of prevailing dogma. You can be a pragmatic programmer in almost any environment, but the spirit of pragmatic programming is more closely aligned with the Agile methodologies.
Hopefully these tips will help you make the transition to the brave, new, Agile world.
Taking Responsibility
The sign on President Truman's desk said, "The Buck Stops Here," and that just about sums it up. The ultimate responsibility for getting things done, and doing them right, lies with the individual. Now of course development is a team effort, but being in a team doesn't mean that you have to lose your personality, nor does it mean that you can stop taking responsibility for the work you do.
Taking responsibility is one of those unfortunate phrases that sounds much like the title of a lecture your parents gave you as a teenager. But we're concerned with much more than simply returning the family car by 10 p.m.; taking responsibility works on many levels, and is a powerful way of propelling your career forward.
Take responsibility for yourself and your career. Learn new technologies and techniques, even if they're not directly relevant to the problem at hand or your current project. For example, a group of pragmatic programmers have recently started the Language of the Year club, in which developers work in their spare time to learn a new (and offbeat) programming language. For 2002, they're learning the functional language Haskell.
Take responsibility for your work. Don't be like "Fred," who isn't real sure about his code but checks it in anyway, relying on his teammates to sort out problems that arise. That's not taking responsibility—that's hiding behind your team. In addition, Fred will accept delivery dates that he knows he can't meet, and will promise interfaces that he knows he can't deliver. Not only is this whole process wasteful and inefficient; it's downright rude to the rest of the team.
Pragmatic programmers are different. They're honest about their capabilities and aggressive about applying those capabilities effectively. Remembering Pragmatic Tip No. 4, "Don't Live with Broken Windows" (named after the Broken Windows theory of urban decay), they don't let problems in code or process fester and continue to do damage—they fix problems as they find them.
Take responsibility for your team. Quality comes from individuals, but success comes from teams. But just like marriage, making a team work well takes effort and dedication. Communicating is difficult, so we need to find ways of making it easier. Use rituals (like the start of day stand-up meeting) to make communicating a habit. Use the lightest-weight form of communication that's sufficient. If you need to discuss an architectural issue, don't spend hours putting together a memo full of UML diagrams and extensive descriptions. Instead, find a spare whiteboard and brainstorm it face to face. Use internal web sites, Wikis, and information radiators to get information out in front of people.
References
Wiki: Bo Leuf and Ward Cunningham, The Wiki Way: Quick Collaboration on the Web (Addison-Wesley, 2001, ISBN 0-201-71499-X).
Information radiator: Alistair Cockburn's fancy term for stuff stuck to walls. See his book Agile Software Development (Addison-Wesley, 2001, ISBN 0-201-69969-9).
Both success and failure are shared, so lame excuses that "It's the team's problem, not mine" won't work anymore. Fix problems as they occur, because once a team gets used to sloppy work, they'll start producing sloppy code. Always look for ways to improve the team's process. And don't just look; go ahead and improve the process as your understanding grows.