Slashdot Mirror
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.
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.
I, like most software engineers I know, are most assuredly not agile. Lumbering, bloated, super-sized or fat perhaps, but not agile.
The review here inexplicably links to B & N, who offer the book at a fairly high price compared to Amazon.
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.
liqbase
when you can limbo dance all the way to the office.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
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.
Crack - Free with every butt and set of boobs
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.
"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.
I'm afraid you've made it very clear that you haven't read the book and don't understand what the hype is actually about. Please refrain from "knowing" in the future unless you can back up your opinions with some credible insights.
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.
Let me introduce you to my very own DMCA-protected encryption key: BC 1B 64 4A 8D DE 49 E8 C3 7D CC EE 1A AD EE
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:
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/.
...all you actually need. Good code comments are nice, and explicit variable naming (instead of lazy naming) are pluses as well.
;). 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.
"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
Loading...
Martin Fowler has written a few words on the subject Is Design Dead?
...or two ;)
Highly recommended, grab a cup of coffee
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
"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.
I meta-moderate because I care.
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...
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
Exactly. We have just a small team of coders doing various projects and take pride in modular development that makes it easy for us to use each others classes when we design a program. It's easy to do while in the safe haven of developers hands. Then it get implemented and all of a sudden X feature needs to be implemented and Y data needs to be stored in Z class (unknown before despite countless design meetings). Now we have a choice, Take the time to modify all these nice classes so they have the added capability and still work together nicely and are adaptable, or throw enough code at them to get your features working and data stored immediately (which happens to be when they want it after it has been released).
You just can't think of everything before hand, and after the fact, you just may not have time to do things properly. Although it may save time in the long run, the short run is usually made far more important by users/bosses.
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.
Let me introduce you to my very own DMCA-protected encryption key: BC 1B 64 4A 8D DE 49 E8 C3 7D CC EE 1A AD EE
That would be the latter, actually. I am indeed to lazy to tell people what they should already know.
:)
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.
Hang on... you're a racist? I will in no way take advice from a racist.
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.
Chernobyl 'not a wildlife haven' - BBC News
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.
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!
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 and integrate formnal methods into your agile approach. You want structure? Try something like ESpec 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.
Craft Beer Programming T-shirts
That's your opinion... and incidentally, by labelling my post "idiotic rambling from one who obviously has no Agile experience," you've made it pretty easy to write off mine, haven't you? Sounds oddly familiar to something you seem to have a problem with.
Something to think about.
No, that's just curry.
There are some good parts of Agile Development. But unfortunately, it's greatest impact has been as an excuse not to have a process.
Don't blame me, I didn't vote for either of them!
If:
- your team can't say yes to nearly all of the points on the Joel test
- 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.
Barnes and Noble is selling this book for $29.95, but Amazon.com is only selling it for $19.77!
Save yourself $10.18 by buying the book here: Practices of an Agile Developer. That's a total savings of 33.99%!
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.
I was a contractor with all different companies for 8 years. I worked with lots of contractors, American and Indian, and we often went to work on some of the same projects together. I know what that short term thing is like... nasty. But Indians always managed to write the worst possible code, and didn't give a shit. Most of the time they were just copying samples from me or another American, and copied and tweaked, not really having any clue as to what they were doing.
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!
To the making of books there is no end, so let's get started
"... 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 .."
THERE is something I can agree with.
I believe someone else in here said most of these things start with a couple good principles and build a whole lot of crap around them. It's my opinion that the flexibility of 'Agile' programming (I hate typing those stupid quotes in there, but I refuse to use that stupid buzzword without them) is mostly, if not completely, theoretical, and that the benefits it promises are mostly -- again, if not completely -- lost in execution.
Think of the waterfall model... it sounds logical. Then you get into production, bad stuff happens, and suddenly your plan is wrecked, you're spending extra time and money to adapt your project, and the deadline you gave your customer is still there, but now it's utterly unrealistic.
Now think of the same project, started with... 'Agility?' Now you have a goal and a direction, but no solid idea of what exactly you're building, only a set of features and how they have to interact. I have an extremely hard time believing this is a good thing. Not only is this -guaranteeing- the exact kind of "that should not do that, this should work that way" that comes with most methods, it prohibits you from looking at the big picture in any meaningful capacity (yes, I consider that a valuable thing to do).
So that's my long-winded agreement++.
> 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!
there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
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.
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?
"It didn't make a difference, he didn't even know what he wanted,"
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!
A screwdriver is a good and useful tool, and it's designed for tightening screws. However, you can also use a screwdriver to pound in a nail. Heck, you can do it in at least three ways. That does not automatically make any of them a good idea, nor does it make hammers obsolete or less effective.
I made the mistake of seriously oversimplifying my opinion on this matter, which made it seem that I have no idea what I'm talking about. I do know more about 'Agile' development than you might assume. I still consider it a bad idea, and I believe that within a few years, this position will be vindicated by the decline of this method, which will almost certainly be relegated to the same sort of cult following enjoyed by the Atkins diet and the Rocky Horror Picture Show.
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.
I found this book used, and love it. Nothing in it is "new," of course, but the little bits of wisdom are very nicely organized and presented. I thumb through it the night before a job interview, and I always am able to pick something out that helps me.
"After all, an inflexible plan is a bad plan."
Rummy? Is that you? How's unemployment?
I agree that there is hype around agile methods, and programs of "how to be agile" that suggest a wide range of practices of dubious extra merit, but package the whole thing up as an "agile methodology" etc. Then again, there is some merit to the approach, and developing early testable specifications of what you intend to develop, and against which you can verify any further code you actually develop, is probably a good thing. Whether having two people sit next to each other to code, or having trendy names for your meetings, etc. has much merit is a little less clear. Agile will undoubtedly remain around, it will just become tempered with common sense and a lot of the hype and trendy named aspects of it will get trimmed away.
Craft Beer Programming T-shirts
EXCELLENT comparison to the waterfall model. Its my experience (ymmv) that almost no one does waterfall in practice, and, equally, almost no one does _insert favorite agile methodology here_ in practice. I tend to think of myself as 'agile' (as opposed to...what, I wonder?), but that's because I tend to define it in terms of the Agile Manifesto (http://agilemanifesto.org) rather than conformance to any specific methodology.
In my opinion, if you read the first page of the manifesto and you find that you agree with their four main points, then chances are you will be more comfortable in an agile environment than a non-agile one. If you're not in one (you'll know) and you'd like to be, pick up a book or two and see if there are ideas in there that you could use. As an example, parts of XP are really good and easy to implement, and other parts (pair programming comes to mind) tend to be less applicable to most teams. Or another example, you can adopt automated testing without necessarily doing full-blown TDD ( aka "only write code when there's a test case that fails" ).
As far as the specific, 'formal' agile methodologies go... leave those to the consultants. zealots, PHB's and other buzzword-compliant types.
Go back 20 years, and I think that was just called something like "separation of interface and implementation", "separation of concerns", or "information hiding". I guess "Agile" is easier to type, but it doesn't strike me as substantially different. The more things change, the more they stay the same.
How, may I ask, do you develop? Do you even develop for a living? If you don't, then you can't really make any criticism on agile methods.
Traditional methods (waterfall, prototyping, etc) are just a carry-over from physical manufacturing. You specify requirements, design the product, produce it, sell it to customers, and provide regular maintenance. No one ever stops the assembly line in the middle of an automobile plant saying "whooooaaa hold up, our customers want 4 more square feet in the trunk and the steering wheel on the right side, back it up!." However, this scenario happens all too often in software. Make the wrong design decisions early, and requirements changes later in development can potentially be very costly. In fact, some projects just start over because it's cheaper. Software is a different beast because it is intangible.
Agile methods aren't "planning to not have a plan." Agile's plan is to prepare for future change, and involve the customer in the development process to make sure they are getting exactly what they want. This helps ensure much higher quality in software.
Agile is new, and it's still an immature science with less research behind it than other methods. Is it the silver bullet to software quality problems? Probably not, but then looking for one is a pipe dream. I personally believe a combination of traditional design and agile is the best way to go.
I got nothin'
Rather than click parent's link, this plain-text link takes you to the same discount:r agmatic-Programmers/dp/097451408X
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.
Tag lost or not installed.
http://www-inst.eecs.berkeley.edu/~maratb/readings /NoSilverBullet.html
Insurance has a concept called churning. That's what these new fads sound like to me for programming.
Actually, most successful software uses the waterfall model. It's the only model that works, so it's why it's being used. In fact, it's the core of Agile! Waterfall doesn't have to be a two year project it can be a one week iteration. As long as you plan before you code, you're probably doing waterfall.
Analyse, Design, Implement, Verify, Deploy, Maintain, Repeat.
Do you try to figure out something about what the customer wants right up front? Do you design the software before you write code? Do you do a full systems verification before you hand it off to the customer? Do you go back and do the same thing for the next version? If so, you're using the waterfall model!
There's nothing in waterfall that precludes pair programming. There's nothing in it that says you can't write unit tests the same time you're coding. There's nothing in it saying SQA can't do integration testing on every iteration.
Don't blame me, I didn't vote for either of them!
I'm beginning to think that working with customers to develop a specification is actually a suffciently hard job that it should be a specialised position - lord knows enough developers seem to have little in the way of an idea about it.
There's a job title of "sales engineer" though too often the person AND the job the person fills falls way short of the goal.
Tag lost or not installed.
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.
-- jchenx
So its true... when all you have is a hammer, everything looks like a nail.
This is the hangover from Extreme Programming and downsizing. Welcome to deferred costs.
Well programmers should be productive.
Damn! Just used my last mod point earlier today, too.... You get +5 Imaginary Kudos for that. Best joke I've seen on /. in quite some time.
Programmer: an ingenious device that converts caffeine into code.
It's very easy to say that you'll get your interfaces correct right away. But that's never the case. Anyone who suggests that it is is a complete fool.
.NET.
It doesn't matter how much thought or effort you put into your interfaces. They will be affected by change. Java is a perfect example of this. No matter how hard they tried, the developers of Java code during the 1.4.x and earlier era would have never have been completely able to ensure that their APIs would mesh well with the 1.5.x language features. Sun themselves managed to keep a decent level of backwards compatibility, but the class library is really beginning to get crufty. There are many Swing classes, for instance, where enumerations should be used. But due to backwards compatibility, they're still forced to use type-unsafe integer constants.
Cruft is a problem that Microsoft really faced quite badly when it came to the Win32 API, just because it changed so much from the Win16->Win32 transition, because it differed between the NT and 9x branches, and because it could not take future developments into account when first developed. API cruft is one of the main reasons there's been a push to Windows.Forms with
Agile methods face reality. They acknowledge that there will be change. And instead of pretending that API changes won't take place, they just accept that they will. Not only that, but then most take steps to ensure that the effects of any changes are mitigated as best as is possible.
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.
Many methodologies mandate quick stand-up meetings each morning. This lets everyone on the team know what everyone else is doing, without forcing them to read pages of documents. It sounds like your scheme cuts out the rest of the team for the most part, only focusing mainly on yourself and the developer(s) directly making the changes.
Pair programming, as mandated by XP, also helps propagate information throughout the team without needs to resort to documentation. Frequent pair rotations allow everyone to work with everyone else, increasing everybody's familiarity with the codebase. Thus if one person leaves, or gets sick, or dies, etc., the team as a whole is still mostly aware of what that person's involvement was.
Mailing lists, web forums, and so forth also allow for rapid developer communication. Best of all, archives exist of those, allowing for rapid future reference. Searching for information about the change somebody made to a particular feature is often far easier with digital archives, rather than trying to sort through pages of paper modification memos.
I wouldn't consider such basic communication methods to be "strange practices". If anyting, they get more of the team involved, at least relative to your company's scheme. Often, that's the best thing to do. Then everyone has a basic idea about what the others are working on, who and what may be affected by changes, and so forth.
There doesn't seem to be much between agile, and simply "being a good software engineer", which includes:
- Building stuff fast (Usually a good thing)
- Being ready to refactor if it all goes a bit 'Pete Tong' (Another good thing)
- Writing clear and commented code a junior developer could maintain (Developers will love you)
- Being always ready to assist and/or mentor other programmers where required (Bosses will love you)
Expressed this way, nothing seems particularly contentious, though it definitely de-emphasizes the "centralized control" of the fabulously craptastic "Waterfall Method". Rrrrrr.
-- "It's not stalking if you're married!" My Wife.
Yeah, you know, the car analogy fits like a glove. Look at the god-awful Pontiac Aztec POS !!!! You really think that they would seriously have sold that thing if there was *any* way they could have done another iteration, refactored, started from a blank sheet of paper etc., etc.
In that case, GM was practically bankrupt, and they had to take whatever shit the 'waterfall' car design process spat out on the first turn of the crank.
-- "It's not stalking if you're married!" My Wife.
Yeah, these jackasses have to put something on their timesheet, so they jack-up shitloads of code, one module at a time. mo-fos.
You said:
Well, what does it matter, imho this whole agile, XP stuff is made up by crackmonkeys anyways.
If you want to software that works then you need three things:
- One Architect (or a team that acts like one)
- A bunch of highly skilled codemonkeys
- A plan which is turned into a spec by the architect and which only changes around *pre-defined* joints
Most projects that I have encountered failed on all three of these points and tried to make up
by going after "agile practices", standup meetings, pair programming and all that rubbish.
And most of them didn't even notice that not even the best process (if its worth a damn) can make
up for the lack of any of the above. Not a bit.
If you don't have an architect then you don't even have to start. Your software will be flawed from the getgo
and the accumulating design failures will make your work slower and more expensive every day.
If you don't have good codemonkeys but rather buy three "fresh'outta'college" students for the price of one
qualified hacker (cuz 3 for the price of one is a great deal, right??) then you're doomed for the architect
either leaving early pissed or, worse, him sanctioning that kind of staffing due to a vested interest in
a longer chain-of-blame (which tells you all about how good of a choice he was).
If you don't have a plan and stick to it then you're lost in either case.
Software as flexible as a car that can be turned into a plane overnight is a pipe dream.
You either know what you want to do or you don't. In the latter case you shouldn't even start either.
None of that can be fixed with any kind of process. Otoh, a qualified team already
has or will quickly develop whatever process works best for them.
All this XP nonsense is made and picked up by the clueless PMs and PHBs crowd that's
always in desperate need to justify their failure. Which is good. For the people who
actually get work done. You spend your time on tweak, tune and blame the process.
Meanwhile those with a clue just sit down and build youtube.
Thanks, please keep writing these books!
Why? Because most of the development teams can't do it right. And when they do it WRONG, it causes support personal workloads to multiply. We have our "team" testing agile right now. So far, in the last two weeks alone, they have changed their tables definitions 10 - count them, 10 -- times. Under normal development, I can expect 2 or maybe 3 in that time. We can't afford more help like this.
Buy.com sends me unsolicited SPAM every day. I've never bought anything there, and certainly have never entered any email address into their site. Yet I receive the SPAM.
Do not reward SPAMMERS with your money.
A better way to put it would be: When all you have are nails, use a hammer!
Software, like hardware, should be planned before implemented. You get blueprints before building a house. You get a diagram before burning the circuit. And you design your software before you write it. Twenty five years of programming life, and I STILL can't understand why people have a problem with this concept.
Yes, you can overplan. The "classic" non-iterative waterfall model fails because of this. But just as bad is underplanning. Too many developers are latching onto Agile as an excuse to underplan. They're tired of writing requirements and getting them approved, so they advocate Agile and then pretend their skunkworks prototype is a product.
You also test your software *after* you've completed it. No matter how much unit and integration testing you've done during implementation, you STILL need a complete systems test on the FINISHED product. This is another misuse of Agile, to excuse the lack of adequate SQA testing. You can certainly write your tests before and during implementation, but you still must perform the tests *after* implementation complete.
Waterfall means you plan, then implement, then test. All the rest is variation on this theme.
Don't blame me, I didn't vote for either of them!
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.
Perhaps the people who pay for the development of software are finally sick of not getting what they want.
how to invest, a novice's guide
If you really want to know the secret to writing great programs I will share them with you below. These secrets always work and never fail regardless of who you are or what you do.
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.
Always check return codes always!! In fact you should have a macro in your IDE that wraps whatever your about to think about calling in an if statement.
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.
If you are writing code to allocate something, in the same breath write the code to deallocate it even if its hundreds of lines away from where you are.
assert is your friend. Honestly it is your best friend, better than that hot programmer chic sitting next to you. Being assert happy to the heights of paranoia will pay off when you least expect it at first and when your like OMG I am so lucky I listened to that anonymous poster on slashdot and went assert happy because it just saved my ass you will happily go assert happy to the heights of paranioa too and recommend the same of your friends. Don't just call assert() write entire functions that apply every possible constraint you can think of to your data structures even if you know it will never happen... This will waste lots of CPU cycles keeping your hands warm in the winter.
That goes without saying. But these same people are the ones who refuse to read Fred Brooks. Most other industry have gotten past fantasy and into reality, but the software industry still insists there must be a magical silver bullet out there.
Don't blame me, I didn't vote for either of them!
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:
10x more insightful than the whole agile crap you find in 20 useless books
"There is nothing more frightful than ignorance in action." Johann Wolfgang von Goethe
>Analyse, Design, Implement, Verify, Deploy, Maintain, Repeat.
You've just completely left out the TDD-ness of Agile here then. Also the refactoring that makes your design Emergent. That would make it:
Analyse, (reafctor if Needed), Design, Test (unit), Implement, Verify (test!), Refactor, Test (functional, integration), Deploy, Refactor, Maintain (Automate), Repeat.
So, testing and refactoring all the way then? mmmm Agile.....
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:
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. 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
-- Butlerian Jihad NOW!
What you describe sounds more like XP which is part of Agile but is not Agile in it's entirety.
Of course people from the Third World are going to lie to dumb, rich Western people if their families' welfare depends on it.
Good luck to them.