Practices of an Agile Developer 172
Cory Foy writes ""Whatever you do, don't touch that module of code. The guy who wrote it is no longer here, and no one knows how it works." In Practices of an Agile Developer, Venkat Subramaniam and Andy Hunt put that quote as an example of something we are all afraid to hear, but probably have in our careers. They then go on to list a collection of practices which can keep you from hearing, or worse, saying that phrase. How do they do?" Read the rest of Cory's review for the answer.
Practices of an Agile Developer | |
author | Venkat Subramaniam and Andy Hunt |
pages | 184 |
publisher | Pragmatic Programmers |
rating | Buy |
reviewer | Cory Foy |
ISBN | 0-9745140-8-X |
summary | A book to become a better developer (even without the agile part) |
I was excited when I received this book. Having gotten the chance to meet and talk with both Venkat and Andy, I knew they were passionate about getting developers to understand how to deliver value to the customers. Both are proponents of Agile development in one form or another (XP, Scrum, Crystal etc). But rather than try to sell you on one of the methodologies, they laid out seven goals: Beginning Agility, Feeding Agility, Delivering What Users Want, Agile Feedback, Agile Coding, Agile Debugging, and Agile Collaboration
In the first, Beginning Agility, they lay out the basics of becoming an Agile developer. Things like Working for Outcome (in other words, don't blame people for bugs, find out how to fix them and fix the process that caused them) and Criticize Ideas, Not People. Or avoiding the pitfalls of making quick hacks without trying to understand why the hack was necessary (Quick Fixes Become Quicksand). They finish up the chapter with a key word I personally feel is absolutely necessary in software development — courage. They put this in the context of Damn the Torpedoes, Go Ahead. In other words, if the code you are working on is stinky, and you'd like to throw it away, don't be afraid to bring that up. Or if code you are in the middle of building suddenly becomes the wrong direction, stand up and explain that (being sure that in both circumstances you have alternatives for getting it on the right track).
The second chapter, Feeding Agility, discusses ways to keep the flow going while being Agile. Things like Keeping Up With Change remind us to keep our skills sharp and honed. Invest in your Team shows that if you don't bother to spread your knowledge, they'll be unlikely to spread theirs with you, and if the goal is to deliver the best product we can to our customers, that just seems counterintuitive. Of course, it is just as important to Know When to Unlearn. Sure, that ASP solution you've had for 10 years works Ok, but that shouldn't stop you from exploring other new technologies. When you don't understand something, you should Question Until You Understand and finally Feel the Rhythm that Agile brings.
Now comes the contentious part. If our goal really is to deliver the most value to our customers that we can, then it makes sense that they should be able to drive the process. In Delivering What Users Want we hit some turbulent waters with topics like Let Customers Make Decisions, Let Design Guide, Not Dictate, and Fixed Prices are Broken Promises. But, to me, this is one of the most important chapters, and they do a good job of explaining how to accomplish all that with things like Getting Frequent Feedback, Automating Deployment Early, Integrate Early, Integrate Often, and Keep It Releasable. In addition, the use of Short Iterations and Releasing in Increments helps keep the flow going and communication with the customer high.
In order to keep up with the high level of customer communication (and confidence), you are going to need assurances your system is working properly. In Agile Feedback, Andy and Venkat discusses ways to get feedback in ways other than from your customer. At this point, if you've been on traditional projects, you are probably thinking the only way you could do this is with Angels on Your Shoulders, which they explain how to get with a safety net of automated unit tests. To really get a good sense of how to keep the design clean, they use techniques such as Use It Before You Build It and running it on a build machine other than your own since Different Makes a Difference. Finally, to understand how you are really doing, you have to Measure Real Progress which you can do through Automating Acceptance Testing (using something like FitNesse). Finally, you have to Listen To your Users. Similar to the way that you should treat compiler warnings as errors, customer complaints are a sign that something is wrong — especially if it is a high number of customers experiencing the problem.
Now that you are Agile with your customer, the authors begin to target the specific code you are writing in Agile Coding. This is a list of some key tenants of good development, such as Programming Intently and Expressively and Communicating in Code (and not chiefly through comments, either!). But there are some practices that are harder, but just as important like Keep It Simple, Actively Evaluate Trade-Offs and Code in Increments.
No matter how hard we try, though, defects still creep in. Or, we don't get the chance to work with pretty Greenfield code, but are dropped in the middle of a big ball of mud. How do we get out? In Agile Debugging, Andy and Venkat cover some great techniques including Warnings Are Really Errors (mentioned above), Report All Exceptions, and Provide Useful Error Messages.
But one of the techniques was something I had not done before, and I thought was excellent — a Solutions Log (also called a Daylog). In other words, when you come across a problem, document it, and when you solve it, document it. No doubt, you'll come across that problem again, and when you do you'll be glad to be able to go back and figure out how you solved it — especially if you don't have the code you fixed it in the first time. (I have a tendency to record anything I come across that I know I will see again on my blog, and I tell you that typing a question into Google and the first result being your own website is the perfect way to make you feel like a total moron).
The final section, Agile Collaboration, is my idea of a dream team. First, you have to Schedule Regular Face Time to talk about what is going on in the project — especially if you all are working on the same code base! You have to be able to practice Collective Code Ownership (meaning anyone should have the knowledge to change another part of the system), and also means that Architects Should Write Code. To help grow the team, you can Be A Mentor, but to do it effectively you have to Allow People To Figure It Out. Some final practices are around respecting your team by Sharing Code Only When It's Ready, being available to Review Code, and Keeping Others Informed about what you've learned.
I enjoyed the layout of the chapters too. Each one starts with a "devil" which often times was saying something I've heard on one team or another. It finishes with an "angel", and a section of what it feels like to be doing the practice. Andy and Venkat also pepper the text with plenty of real world situations that reinforce just how bad software development can be.
In summary, if you want to be a better developer, but think Agile is a misused buzz word, go to your local bookstore, put a small piece of masking tape over the word "Agile" in the title, and buy this book. You won't regret it.
You can purchase Practices of an Agile Developer from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Update on the link (Score:3, Informative)
Enjoyed This Book Myself (Score:5, Informative)
I read this about two months ago, and mostly enjoyed it. I don't remember anything earth-shattering or particularly enlightening from it, but then again I had previously read some other books that probably put a damper on what this book had to teach me:
Seems like most of what the Agile book had in it was for me a rehash of the three Pragmatic books. So, to me, a good book by itself, but I'd recommend the three Pragmatic books instead of you have the time for that much reading.
Audio Interview With Andy Hunt About The Book (Score:2, Informative)
Worth a read (Score:5, Informative)
Highly recommended, grab a cup of coffee
Re:Buy? (Score:4, Informative)
You have not accurately represented Agile Development, you have created a misrepresentation so that you can disregard it more easily. Either you do not know what Agile Development is or you are too lazy to honestly critique it.
Please read the following Wikipedia entry for a more formal definition of the logical fallacy you have committed: http://en.wikipedia.org/wiki/Straw_man [wikipedia.org].
Re:Update on the link (Score:5, Informative)
Price Comparison Table [addall.com]
Buy.com has it for $2 cheaper than Amazon.
Re:Code modules start with great intentions (Score:1, Informative)
That's the neat thing about agile, you can implements pieces of it at the team level--pulling the responsibility for certain things down a few rungs. Your refactoring time isn't scheduled separately but becomes part of your standard quoted times. Generally this should also improve your quoted time because it's much easier to work on fully factored code.
It's not in any way lying, cheating or being sneaky--it is, in fact, just programming well. If you are not constantly refactoring your code, talking to your co-workers and interacting with customers (at least a marketing rep) whenever you have the chance, then you're really not much of a programmer.
Re:The Pinkies, they say STOP! (Score:2, Informative)
Looks like an affiliate link to Amazon (Score:3, Informative)
http://www.amazon.com/Practices-Agile-Developer-P
Or if you still don't trust MY link, go to amazon.com and put in the title Agile Developer.
Fair disclosure: I have used books for sale through Amazon, though not this one.
Re:what a coincidence (Score:4, Informative)
Yes, he's very enthusiastic about whatever subject he's teaching. Too bad he took so much time out of class to travel and lecture at other companies, though.
You might want to read a dissenting opinion [blogspot.com]. Having been on both Agile and non-Agile development projects, my own experience is that some Agile techniques are beneficial for some projects, but anyone who says that Agile is the magic pill that will ensure maximum productivity is both smoking and selling you something.Re:The Pinkies, they say STOP! (Score:4, Informative)
Someone else already pointed it out, but those are the sections. Trust me, I wouldn't have written it that way if it wasn't.
Buy.com is a SPAMMER (Score:1, Informative)
Do not reward SPAMMERS with your money.