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.
Code modules start with great intentions (Score:5, Insightful)
We have all got our monsters.
Re:Buy? (Score:4, Insightful)
Re:Good development practices... from an Indian?!? (Score:4, Insightful)
Can't imagine why you posted AC there, stud...
My experience with bad code like that has been when a short-term employee was pulled in and forced to work with a short-term mentality... which actually all falls back to bad managers. When your boss instills the "throw it together NOW so it works (barely) NOW and move on to the next project NOW" mindset into the coding crew, you're pretty much guaranteed to be stuck with smelly code. Who the actual programmer is will have little to do with it.
I will assume for your sake that your limited experience with short-term coders has mostly been around the intersection of "H-1Bs" and "contractor programmers" and therefore you generalize "Indian". One day you'll learn that it's the "short-term" part of this equation that hurts the code quality, and not the coder's non-code-related characteristics.
Re:Buy? (Score:1, Insightful)
I spent a couple days reading about 'Agile' methodologies. No, that's not enough time to learn everything about them, and no, I am not an expert. However, I do not believe I need to know every detail of 'Agile' to realize that it is a seriously flawed way to look at development.
Yes, I severely oversimplified, and yes, that could be taken as a straw man if I based my own opinion on simply that or was attempting, with that statement, to argue 'Agile' fans over to My Side of the Fence. I was not, however, so I don't feel too bad about my logical issues in this particular instance.
It's a comment on a review, not a full-fledged "Why You Should Avoid This Crap like the Plague" dissertation. I disagree with you, but don't really care enough to attempt to change your opinion.
Re:Buy? (Score:3, Insightful)
According to the article, Agile implies "Let Design Guide, Not Dictate". That sounds a WHOLE lot different than "Don't Design". My understanding is that the idea is to have an ADAPTABLE plan. After all, an inflexible plan is a bad plan.
arrrggghhhhh (Score:3, Insightful)
"Agile" programming? ATF, sorry, but come on.
Like all the other programming fads, there are elements of good standard practices that, if you've been writing code for any length of time, already do, but then they go on to preach their own brand of mumbo jumbo.
Now, some PHB is going to want to push "agile" programming. Just stupid.
OK, rant. THE CUSTOMER SHOULD NOT DRIVE DEVELOPMENT. There I've said it. The customer has no figgen clue about what development is or means.
Short story: I was working at a company years ago, a VP of development wanted to be able to dial out and use a terminal programs on his PC from our office phone system. I asked him, point blank, tell me exactly what you need. He responded, "I just need to be able to connect to a modem and dial out." (exact words burned into my brain)
So, we bought $20,000 worth of phone equipment that did just that, alowed a PC's modem to be plugged into a wall, and dial out.
He came to my office and said, I can't use this system. I asked why? He said the modem banks weren't "hayes compatible." I looked at him, told him his exact words after being asked "exactly" what he needed, and he said (rather annoyed) "well, you should have known I needed "hayes compatible."
Moral of the story: the user don't know squat about what they want, let alone are able to navigate the technical landscape.
As engineers, we have to learn with the customer knows and apply it to the program, but do not confuse this with letting the customer drive!
Re:arrrggghhhhh (Score:3, Insightful)
If the person paying you to write software doesn't get to tell you what the software should do, who does?
I went to a fancy restaurant like that once. You pay $150 and get whatever the meal of the day is. Unfortunately, the main course was salmon and I'm allergic to fish, so I left. I heard it was nice, though I've never gone back.
Re:Code modules start with great intentions (Score:1, Insightful)
Agile is for those who have mastered the basics (Score:4, Insightful)
If:
- your team can't say yes to nearly all of the points on the Joel test [joelonsoftware.com]
- if you spend more time fighting fires than working on your project
- if you couldn't honestly say your team is better than average
- if your managment is more focused on getting it out the door than getting it right
then Agile is not going to solve your problems. The basics of good software development have to be there first.Agile helps a good team become excellent, it doesn't fix the problems in a dysfunctional team.
Re:arrrggghhhhh (Score:4, Insightful)
Engineer says: "B.S. - Be Specific", what is your app, what is the requirement, why do you need to dial out, what do you need to connect to, etc. And in any case, once the customer asks for "X", signs off on it, and it turns out they really needed "Y", it's best to get that over with as soon as possible and start working on "Y".
The user actually knows *exactly and precisely* what they want, it's just that they have a tough time expressing it most of the time, and it's quite probable that what they want is not possible in the timeline / budget / etc. that they have allocated for that need.
So, figure out what a customer *wants*, keep them FAR away from anything remotely technical, but make sure the technical decisions that the engineering team makes satisfy what the customer *wants*.
--Robert
Re:arrrggghhhhh (Score:3, Insightful)
Re:Code modules start with great intentions (Score:5, Insightful)
Just last week I got asked to put some quick hacks in one of my clients sites to allow for some more discrete rights management for their client-facing site because they had one large client ask for it.
I could have written an extra page that those clients get redirected to, some dangling crud in the database to support it and maintain it in an ever growing parallel with the rest of the system, or some other ugly hack that leads to unmaintainable code. That was specifically what they asked me to do.
Instead I proposed that I extend the internal rights management used for employees to handle the client side of things, which was quite a bit more work, and a fair bit more expensive, but "Oh by the way, if we do it this way, I can trivially exploit this change to allow you to also discretely control rights for all this other functionality your clients are exposed to, and allow you to do it on a client by client basis in the future without needing to pay me to change the code."
Don't just tell people that in some abstract fashion your "good coding techniques" are superior to the crufty crud that seems to work fine. Think of all the things that become trivial for you to deliver because of those good coding techniques, and make them part of the package.
In other words, don't tell them you can take 5 days to deliver a "good" implementation that delivers the same functionality as working 2 days to deliver a "cruddy" implementation.
Instead, tell them you can take 7 days to deliver a "good" implementation, and it will include all this extra functionality that they weren't asking for but what the hell, it's good value and it's the right way to do things too, so why not.
If you can't find some way or another to make doing it the "right" way pay extra dividends that users can appreciate, maybe it's not really the right way...
Re:Buy? (Score:5, Insightful)
This is completely wrong. Agile recognizes that change inevitably happens but that it is chaotic and unpredictable. The mistake you've made is that you assume you can predict the change. This is precisely the mistake that Agile seeks to address. Agile recognizes that it is not likely that you (or anyone else) will be able to predict the nature of changes in the future.
Nowhere does agile prescribe anticipating where code is likely to change. In fact, quite the opposite, agile touts the notion that you build for today. Tomorrow you refactor what you built today. Agile proponents understand that it is often a complete waste of time to build adaptive frameworks that depend on gross assumptions about the kind of changes that are predicted (rather than known).
Agile does have a plan. The plan is: code something that works and build tests that test what you've code against what requirement the code is supposed to satisfy. The code and the test are built together using whatever information is immediately available.
Am I Missing Something? (Score:5, Insightful)
So you, the technology expert, bought $20,000 worth of equipment on a one sentence verbal spec... and it's HIS fault?
Isn't this a rather collosal, and unforgiveable, failure on your part?
Well, naturally. (Score:3, Insightful)
Well naturally he didn't. If he knew exactly what he wanted, he'd just order it himself.
I don't have quite the background that some here do (6 years in support followed by 8 years in development), but even early on in my career I knew that "tell me exactly what you want" never, ever works. Even for relatively trivial things.
I'd like to know how you found hayes-incompatible equipment though - that must have taken some work!
Mod parent up (please) (Score:2, Insightful)
Re:arrrggghhhhh (Score:3, Insightful)
Ultimately, the customer will be dissatisfied with anything they have a hand in producing, because it will be limited by their own immediate needs.
...and their own imagination.
Can someone please inscribe this on a granite tablet and install it in the British Museum for all to see?
That's a bad attitude (Score:3, Insightful)
It's only natural for customers to be resistant to change, especially if what they have going for them, works. That's why, as engineers, it's partially our job for being effective communicators. Show them some examples of what word processors can do beyond typewriters. But also be honest, and be aware of the disadvantages, and be ready to have long discussions about it.
Too often I run into engineers that are really excited about technology X and all they want to do is use it NOW NOW NOW. Anybody who says otherwise, or gets in their way, or slows the process down, is suddenly a Luddite and "just doesn't understand technology". Those engineers don't get very far in their careers, and understandably so.
Your original post is an excellent example of how engineers should NOT work with customers. Customers rarely know exactly what they want. That's why you have to spend time (sometimes a lot) on flushing out all the details, making sure people don't make assumptions, etc. It's time consuming and not easy, but it saves a helluva lot of time and money in the future, if done right. (And your example shows it)
Unfortunately, these are often skills not well taught in college, since the focus is often just on "can you write good code?". We need more general Software Engineering courses that teach this stuff, to reduce this "code first, ask later" mentality that seems much too prevalent these days.
Re:Am I Missing Something? (Score:4, Insightful)
Re:Buy? (Score:1, Insightful)
Try very hard not to return or throw exceptions (throw() are really gotos in costume) upon errors. Keep a return code throughout and only return in one place (at the end) throughout your function. This will help you manage allocation of resources, locks, transactions...etc with less chance of forgetting to handle something every time an error happens and you feel like bailing.
Releasing resources is what try {} finally {} is explicitly for. Wrap your entire function in a try/finally block and return anywhere you want. For Java, Exceptions are definitely the easiest way to handle many kinds of errors.
Always write error messages, error handling...etc code *last* but leave quick comments so that you remember to go back to each spot and write them. The reason for this is it gets you to recognize areas of similiar errors/classes of errors and treat them as groups improving overall quality and reducing overall time spent. It also prevents you from being lazy and skimping out on useful checking/messages when you have other things to think about. The second pass also provides some opportunity to catch bugs if your alert during the process.
NO. Standardize your error handling FIRST and use it everywhere: