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.
AND I LOVE IT WHEN COCK IS SLAMMING UP IN MY ASSHOLE
Sincerely,
Rob Malda
Slashdot Editor in Chief and Agile Developer
# ply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might b# ply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might b
# ply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might b
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
First post of an agile reader.
I think the Slashdot readership collectively has enough sense to avoid the 'Agile' hype... though I'm more and more concerned that the reviewers will buy into anything that's committed to paper.
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."
Nerds KNOW better.
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 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
Hang on... one of the authors of this book is an Indian? The whole premise of "hold on, don't touch that module" in real life revolves around shitty code written by Indians who lie on their resumes and fuck up everything they touch. EVERY situation that I came across when I was a contract developer was created by some dumbass Indian. Suffice to say, I will in no way purchase a book about development that was written by an Indian.
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
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.
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
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!
Bareback ain't cheap, you know and Amazon kickbacks just don't cover it.
I hope high gas prices are depriving your children, you fucking dumbass.
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%!
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 .."
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!
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.
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.
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
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.
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.
Seriously never hire an upper caste Indian. You find out by mentioning your extended family. The upper caste 'Guptas' can't resist the bait. They talk about how much land/money their family have back in India, tastefully slipping it into a quick amusing story.
Never hire one of these SOBs. They are like the worst spoiled rich kid American, but they cheated their way to a technical degree and a real job to please their families. YMMV but IMHO they are all air thieves.
Lower caste Indians can be competent, even good. Upper caste are just gunning for management where they will make your life even more hell. Nip it in the bud by not hiring them.
Does that make me 'Castest'? Is 'Upper Caste Gupta' a protected class?
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
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!