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.

After discussing this post with colleagues, I was pointed to one more reason to not neglect code reviews. The reason is that after a code review there are two people who know how the piece of code is written, not just the original developer, who wrote it. They know how it works. And, more importantly, they know what it was written for, be it fixing a bug, implementing a new feature or just getting rid of a piece of technical debt. The code review makes people share knowledge - not just some technical tricks, but a deep understanding of the project's requirements, architecture and code base. And it is hard to think of anything more important.

Yesterday I watched Mike Rozlog's presentation at Code PaLOUsa about Static Code Audits. I really enjoyed it. He gave a great motivational speech, advocating the use of static code audits, describing their benefits. I don't agree with Mr. Rozlog's attack at peer code reviews, though. He believes them to be inferior in efficacy to static code audits and he makes his point by bringing in statistics you can't fight. I, personally, think you should not compare these things at all. Yes, static code audits can find hidden bugs and code smells, they can check your code style etc. But, in my opinion, a peer code review is not about finding all bugs. It's about developer interaction, it's about exchange of knowledge. A static code audit can point out the bugs in your code but it cannot tell you how to make your code better (except for the most obvious things). It cannot teach you how to use your tools better. It doesn't teach you how to think and plan. It does...

It was one of those simple-but-nasty bugs that make you cry over them for several hours. The perfectly valid project just refused to start. I've got an error ( see the stacktrace below ): "com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! D:\ (The system cannot find the path specified)". I didn't know why on earth JSF wanted to read the configuration from the drive's root instead of using existing, perfectly legitimate configuration file until I started debugging the Mojarra's sources itself. Then it struck me - I put the project in the "D:\!eclipse\projectname" folder (note the exclamation mark!) and Mojarra just couldn't handle the exclamation mark because of the following code in the getAlternativeJarFile method of the com.sun.faces.facelets.util.Classpath :

- And how long do you guys think it will take us to develop this user story? (The little yellow post-it boasted a proud title of "Synchronization of labile subkernel optimizers") - 5 hours. - No, 7! 12! 3! 48! 20! After about 15 minutes of heated discussion the estimate section was filled with a fresh inscription: “16hrs.” The two-week work schedule had 8 similar tasks, and each of the 5 developers was sure that the team would meet the deadline. - All tasks? By October 18? Consider it done. Naturally, two weeks later it turned out that the project was nowhere near the done stage. The code lacked both "lability" and "subkernelness". There were "optimizers", at times even "synchronized", but the general picture was inauspicious – the plan was foiled, the story was not ready, the product could not be released. Other stories did not fare much better. The Product Owner plunged into silent panic, vividly picturing the visit to Big...

My very first encounter with Agile-methodology can be traced back to 1999. Like many others before and after me, I was left with a peculiar, not exactly pleasant aftertaste. Furthermore, this subjective impression pretty much proved to reflect objective reality with its many hidden traps. At that time the relatively tranquil life of our close-knit outsourcing team was disturbed by a delegation from a metallurgical plant. The messengers wanted us to develop specific software, since their in-house solution had almost given up the ghost. When faced with real production volumes, the program buzzed, glitched, went bananas and croaked, which finally pushed the plant management to the realization that their tasks needed a more adequate solution.