Practices of an Agile Developer

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

The review here inexplicably links to B & N, who offer the book at a fairly high price compared to Amazon [amazon.com].

Re:Update on the link

Say hello to my little friend.

Price Comparison Table [addall.com]

Buy.com has it for $2 cheaper than Amazon.

Code modules start with great intentions

Then real life gets in the way and your first gen mock up becomes live code (after the boss sees it - "but its working, why do you need to rewrite it...") and you curse yourself every time you open that code.
We have all got our monsters.

Re:Code modules start with great intentions

I don't even go near a computer whilst developing - pencil and paper is best.

      (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)

Re:Code modules start with great intentions

Pencil and paper?! Bah! Why get bogged down with those new age mental encumbrances.

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.

Re:Code modules start with great intentions

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.

I think you misunderstood the chapter on "shell programming". See this is what happens when you bring these VB6-ers over to the Linux world. :)

Re:Code modules start with great intentions

Wow, just wow.

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.

Re:Code modules start with great intentions

When you are programming, as a general matter, first comes the comments, second the bound tests,

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".

Agile is for those who have mastered the basics

The parent post illustrates an important point about Agile clearly.

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:Code modules start with great intentions

Good reusable code is empowering. Make them aware of it by giving that power to them. Example:

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...

You are only truly an agile developer

when you can limbo dance all the way to the office.

Courage ...

This was the first book review on here that I REALLY enjoyed. Very informative. I liked the idea of developers showing courage to fight for the right path, although I must add that this is best done without getting emotional or fired up. Courage is great when it is modest and controlled, otherwise you'll just be relegated to an even darker corner and reassigned to mainframe Cobol development.

My methodology is mediocrity

So instead of:

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

"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)." I try to teach a) help desk people b) network engineers c) operators d) everyone I can ...to do these very things. It's called "giving a shit about your work and how it affects other people." Also known as "doing a good job." 'nuff said.

Enjoyed This Book Myself

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:

• Pragmatic Version Control
• Pragmatic Unit Testing
• Pragmatic Project Automation
• Ship It!
• Extreme Programming Explained
• Art of UNIX Programming
• Practice of Programming

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

There is a pretty good audio interview with Andy Hunt about the book at http://perlcast.com/2006/07/12/practices-of-an-agi le-developer/ [perlcast.com].

Feature design documents are...

...all you actually need. Good code comments are nice, and explicit variable naming (instead of lazy naming) are pluses as well.

"I have to implement feature , the requirements doc (if any) can be found at: A synopsis of the feature is: In order to satisfy those needs architecturally, I've decided to implement like because we want to avoid using because it prevents us from in the future..."

These docs are usually a page in a half for a complicated feature that has a potentially confusing architectural design.

The problem isn't in what you do up front or at the end, it is making a developer keep a document up to date. We're incredibly hard working about some aspects of our profession and ridiculously lazy about others ;). Every feature that is implemented at my current company results in the developer(s) producing an informal design doc that is used by the architect (myself) to look out for gotchas/caveats/black-holes and offer helpful suggestions. This usually takes about 5-10 minutes in my office. After check-in and assigning the feature as 'complete' to QA for starting the test plan, there's another 5-10 minute review using the same document and asking "So what changed? What did we forget the first time? Ok, add that to the doc, send me a copy and I'll file it..." This way if, God forbid, a dev gets hit by a truck or just up and leaves we don't have to worry about having no idea what they've done and/or what they are doing at this time. Just one of many different ways to solve this problem that doesn't require exotic or strange practices.

Worth a read

Martin Fowler has written a few words on the subject Is Design Dead? [martinfowler.com]

Highly recommended, grab a cup of coffee ...or two ;)

what a coincidence

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 convinced that it is appropriate for OSS development. He's giving a talk next week about just that, so maybe my opinion might change.

-metric

Re:what a coincidence

I've been very impressed with Venkat's teaching...

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.

...and am convinced that Agile development models are beneficial for commercial application development.

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.

You call that agile?

It's clear that to be an agile programmer, you simply have to Create Catchy Techniques and learn how to Capitalize On the Shift Key. I'm about ready to Pry Out my Eyeballs...

The Pinkies, they say STOP!

Am I the only person who had to Stop Reading the Book Review half-way through because of Capitalisation Overload? There Are other ways to emphasise or to indicate a "phrase from the book" which are much Less Annoying Than Doing This.

Re:The Pinkies, they say STOP!

There Is Historical Precedent For This.

(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.

Re:The Pinkies, they say STOP!

(Disclaimer: I'm the reviewer)

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.

arrrggghhhhh

I just can't stand it. How many books and programming fads must we endure in our careers?

"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

"""He responded, "I just need to be able to connect to a modem and dial out.""""

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

Am I Missing Something?

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."

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?

Re:Am I Missing Something?

Isn't this a rather collosal, and unforgiveable, failure on your part?

Well, he did say that he was working at that company. Past tense. I'd have fired his ass, too.

Time For Study

Nice review. This just reminds me again that I need to take time out regularly to study not only new technology, new methodologies. Thanks for pointing out what appears to be a good book!

Example from a real project (2005)

"... Nobody here is really sure what the code does, the programmer has left. We think that the ?answerset methods were added as part of an incomplete implementation without disabling the static behaviour which we think is of no use. If this doesn't make things clear than can we continue by phone .."

Agile organizations

There's a lot of focus on the methodologies the Developers need to focus on to achive agility. For me the biggest challenge in my current organization has not been the developers doing things the agile way but getting the customer (or in our case product development... the customer's representative) to be able to think in smaller, self-contained chunks. Some of this may be that we are dealing with a complete rewrite of an existing system... perhaps agile is better suited towards incremental improvements of an existing code-base rather than a "port" style project. In summary, our biggest hurdle seems to have been getting the product sponsors to think in smaller chunks. Not in us implementing an agile methodology within engineering but rather across the organization.

Extreme Programming - the Morning After

This is the hangover from Extreme Programming and downsizing. Welcome to deferred costs.

Blah, Blah, Blah

The same old realities that have existed for at least 40 years in software development, but This Time In New Emperor's (Agile) Clothes. But *Now* with Excessive Capitalisation.

Move along people, there's nothing new to see here.

The unfortunate reality is that these concepts _are_ new to an unfortunately large proportion of "hot young programmers"

I'm currently struggling with an application which has all the hallmarks of being developed by programmers who:

• dropped out of Uni because, hey, their skills were more valued in the real world
• think an MS certification is more useful than a degree
• belief "Knuth" is cussing
• have never heard of Steve McConnell, Frederick P. Brooks, Tom Demarco, Edward Yourdon
• Or Lisp

I'll not name names to avoid being sued, but every bug I discover indicates:

• an ignorance of pre-existing solutions in the problem space;
• broken architecture;
• the review and test plan was never written, never mind followed.
• and that engineering governence is totally missing.
• But, dude, relax, all bugs are FITNR [jargon.net]. And have been for years. :-(

In short, as an example of Good Code, it's a bucket of shit and it stinks. And no, it still doesn't do what the users want.

Yes, I've been writing programs for over a quarter of a century. So I'm an Old Coot (tm). But I see these whippersnappers making f@#$%@ups that would have gotten me a quick slap 'round the ears. And claiming that they're doing something 3ll33t and, just, like, so, y'know, waay beyond the comprehension of anyone over 23.

Dude.

It's Crap, Ray, Crap

Re:Buy?

Okay, that's just idiotic rambling from one who obviously has no Agile experience. Agile programming means planning for things to change, as we ALL know they do. It means designing with flexibility in mind--knowing that when plans, features, behavior, etc., needs to change, you've structured the program in a way that makes it easy to do so. It doesn't mean 'not having a plan' or free-form programming with no structure discipline, but it sure is easy to write off the entire idea by portraying it so :rolls eyes:

Re:Buy?

Your synopsis falls into the idiotic rambling category. You have no clue what agile is about.

Agile programming means planning for things to change. . . . [Y]ou've structured the program in a way that makes it easy to do so.

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.

Re:Buy?

"Honestly... no structure, no planning, no discipline, nothing but planning not to have a plan."

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:Good development practices... from an Indian?!?

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?

Honestly... no structure, no planning, no discipline, nothing but planning not to have a plan.

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:Buy?

Honestly... no structure, no planning, no discipline, nothing but planning not to have a plan.

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 of planning with what you have no, and being open to change - that's not "no plan". If you're curious as to why I'm picking on Eiffel as a language for agile development - I figure the percieved incongruity (that, as is apparent by the examples given, doesn't actually exist) of agile development with a fairly strict, planning oriented language like Eiffel might actually get you to pay attention and see what's going on.

Re:Buy?

There are some good parts of Agile Development. But unfortunately, it's greatest impact has been as an excuse not to have a process.

Re:Buy?

> Honestly... no structure, no planning, no discipline, nothing but planning not to have a plan. This is asking for disaster, yet it's so popular that you can't avoid it on trendy tech blogs and even places like Slashdot that are supposed to be "for nerds."

Hello, first of what will doubtlessly be many uninformed posts whose authors clearly have no idea what a typical agile process involves!

Looks like an affiliate link to Amazon

Rather than click parent's link, this plain-text link takes you to the same discount:
http://www.amazon.com/Practices-Agile-Developer-Pr agmatic-Programmers/dp/097451408X [amazon.com]

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:Good development practices... from an Indian?!?

Hey jerky, I personally know Venkat. He is a excellent developer, great author, and a first class guy.

Your post is a waste of valuable bits.