Slashdot Log In
Practices of an Agile Developer
Posted by
samzenpus
on Wed Nov 29, 2006 03:18 PM
from the stretch-first dept.
from the stretch-first dept.
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.
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.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Update on the link (Score:3, Informative)
Re:Update on the link (Score:5, Informative)
Price Comparison Table [addall.com]
Buy.com has it for $2 cheaper than Amazon.
Parent
Code modules start with great intentions (Score:5, Insightful)
We have all got our monsters.
Re: (Score:3, Interesting)
Who wrote the code? You!
You can be sure *you* are the one to blame, not your boss.
If you are working on a mockup GUI, be sure no functionallity is within the demo.
If you are working on a mockup funtional unit, be sure is terrifying ugly so no PHB will think it's ready.
When you are programming, as a ge
Re:Code modules start with great intentions (Score:5, Interesting)
API's first, always. Everything else is easy to change, but if you eff up the API's, you are in a world of shit when they have to change.
Parent
Re:Code modules start with great intentions (Score:5, Funny)
third the job search after you get fired for "wasting so much time" and not being "agile enough to meet the business needs by just getting it done".
Parent
Re:Code modules start with great intentions (Score:5, Funny)
(pulls up another pillow and offers a seat under the tree, on a hill overlooking the valley)
(rolls up a "special cigarette")
Man, I'm telling you. Paper and shit is all good. But, you've got to get real mellow like, and think about the problem (takes a drag on the "cigarette"). Yeah man. Mellow, and stuff. Like - what is the program for. What do I want it to do, an shit. And then after a while you can see it all, algorithms, subroutines, data structures, bounds checks. And THEN you get the pencil and paper - here, want some? (cue Indian sitar music)
Parent
Re:Code modules start with great intentions (Score:5, Funny)
When I get an assignment, I immediately pack my bags for a retreat high atop the canopy in the Amazon. I hunt for food and use the blood of my kill to jot down the design of my project on the backs of baby turtle shells, each representing a piece of functionality. Then I let them loose on the ground and follow them for days. Those that live through the ordeal will have a hollowed place in my design.
Parent
Re:Code modules start with great intentions (Score:5, Funny)
Parent
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.
Parent
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...
Parent
You are only truly an agile developer (Score:3, Funny)
Courage ... (Score:3, Interesting)
My methodology is mediocrity (Score:3, Funny)
The guy who wrote it is no longer here, and no one knows how it works.
It goes something like this:
The guy who wrote it is so stupid, they promoted him, and everyone knows how it works because we all were forced to completely rewrite it.
Not just for codeherders anymore (Score:3, Interesting)
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
what a coincidence (Score:2)
I'm about to finish Venkat's semester long class on software engineering at the University of Houston. Actually I have a team demo in a few hours! (what am I doing on Slashdot.. hehe)
I've been very impressed with Venkat's teaching and am convinced that Agile development models are beneficial for commercial application development. The main advantages are its adaptive planning and methods for predicting how long development is going to take mixed with customer communication.
That said, I'm not yet con
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.Parent
You call that agile? (Score:5, Funny)
The Pinkies, they say STOP! (Score:5, Funny)
Re:The Pinkies, they say STOP! (Score:5, Interesting)
(Unfortunately, that doesn't make it any less annoying...)
XP [wikipedia.org], arguably the 600 pound gorilla of the "agile methodologies," was created by Kent Beck, Ward Cunningham, and Ron Jeffries. It was a direct outgrowth of their work the "Chrysler Comprehensive Compensation (C3) System," and information about their brand new methodology was publicized on a little web site Cunningham had put together.
It just so happened that the "little web site" was the very first Wiki [c2.com]. One of the side effects here is that since each of the XP principles got its own page, it also got its VeryOwnNameInCamelCase. The weird capitalization of the rules is an artifact of agile methodologies' debt to the wiki format.
Or something. I think.
Parent
Re: (Score:2, Informative)
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.
Parent
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: (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: (Score:3, Interesting)
The customer does not pay me to "write software" they pay me to provide a tool that helps them accomplish a task. It is a fine line, for sure, but an important one. It is up to me, and any other engineer, to understand what our customer knows and apply it to what ever we are developing.
Letting the customer drive the product is a bad idea. Too often the customer is reluctant to see beyond their immediate
Re: (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?
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
Parent
That's a bad attitude (Score:3, Insightful)
That's a really bad attitude. Granted, there are some Luddites that don't understand technology, are afraid o
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
It's still possible to say to the customer "We can make exactly what you do a little easier, for $X, or we can provide you with the following extra benefits to your business for $Y - which would you like?". Ultimately,
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?
Parent
Re:Am I Missing Something? (Score:4, Insightful)
Parent
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!
Re: (Score:2)
Time For Study (Score:2)
Re:Buy? (Score:4, Insightful)
Parent
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.
Parent
Mod parent up (please) (Score:2, Insightful)
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].
Parent
Re: (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.
Re: (Score:2)
Rummy? Is that you? How's unemployment?
Re: (Score:2)
I'm honestly not sure what you mean. I guess you could do Agile that way if you wanted to, but it is in no way a requirement. You want discipline? Try Specification Driven Design [york.ac.uk] and integrate formnal methods into your agile approach. You want structure? Try something like ESpec [yorku.ca] to provide a single workbench to structure design, development, testing, and formal verification. And as for planning, well its a matter o
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Hello, first of what will doubtlessly be many uninformed posts whose authors clearly have no idea what a typical agile process involves!
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.
Parent
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.