Good Java Fish

I've seen a number of Agile adopters who thought that switching from traditional requirements specifications to user stories can make their life easier in some magical way.   - Come on! User stories ARE simple. Write three lines of plain text and off you go!   Yes, sometimes that's a fine way to go - if you have deep understanding of the subject in question, and your vision matches the customer's vision. But this requires having a long and successful history of communication and collaboration with your customer , which a quite rare situation. Your customer should be technical-savvy to understand the decisions you make, or he has to trust your decisions completely. On the other hand, YOU have to have a deep understanding of the customer's business, you have to predict his needs - and that's not easy to do. If you don't have this kind of relationship, you risk hearing from your customer something along the lines: "That's NOT what I wanted!" aft

In addition to these posts ( Code review vs. static code audits , Code review vs. static code audits-2 ) I would like to recommend a very insightful paper published by SmartBear Software: 11 Best Practices for Peer Code Review . It has a lot of useful information both for beginners and experienced developers. On top of that, it provides statistics that helps you to understand why you have to implement these practices and what benefits they provide. (Nice thing to have if you have to confront your management about implementing new practices!) I don't have much to say: just go and read it, guys and gals. It's totally worth it.