My email overfloweth with great links. Here is a 2nd edition of squeezed links this month.

• How To Piss Off Development – The Cranky Product Manager shows us the sure-fire way to piss off a development team
• Don’t Build for the Future – Simple title, timeless advice
• Rules to Better Unit Tests – Solid ideas for writing and organizing your unit tests
• Too Many Questions – Advice from Steve Rowe on how to deal with newbies that ask too many questions
• Will My Software Project Fail? – Ensure you have the 3 pillars in place before every project
• Scrum is Team-Driven Development – Interesting article about why SCRUM works. Found it interesting to hear a previous Rational employee say they created software processes to sell tools. Does that make RUP a marketing tool?

If have a great link or article, send it in!

Perfectly fitting with the style of the Pragmatic Programmer series, Agile Retrospectives: Making Good Teams Great is a book for helping teams run effective and fun retrospectives.

Whether you call them postmortem, postpartum, or retrospective meetings; these meetings can help your team iteratively move forward by looking back.

After reading the first few chapters of this book in Barnes and Noble, I committed to buying this book under the pretense it would speak more generally about why teams should hold retrospectives and how to incorporate needed changes back into the process. Upon further reading, this is not at all what this book is about. This book is about providing concrete activities to get your team communicating.

Activities are included for gathering data, insights, and next iteration/project goals. For example, at Sundog we have used a permutation of the Mad, Sad, Glad activity. The activity is simple, draw on a white board three areas labeled Mad, Sad, Glad. You are given (at minimum) 5 post-it notes and are required to fill them out with things that made you…well mad, sad, or glad. When everyone is finished filling out their post-it notes, in round-robin fashion, post-it notes are placed on the appropriate area. Each note is allowed a maximum of 5 minutes of discussion.

If Mad, Sad, Glad seems to simple to be effective, just answer the question – Have I ever been in a meeting where only one person speaks? If you haven’t, consider yourself lucky. Many retrospectives are not effective as they are hijacked by individuals who tend to be heavily opinionated (primarily negatively charged as well). Simple activities outlined in Agile Retrospectives allows for equal participation and distributed opinions.

Chapter List

1. Helping Your Team Inspect and Adapt
2. A Retrospective Custom-Fit to Your Team
3. Leading Retrospectives
4. Activities to Set the Stage
5. Activities to Generate Insights
6. Activities to Decide What to Do
7. Activities to Close the Retrospectives
8. Releases and Project Retrospectives
9. Make It So

The Good

• Teaches methods for managing group dynamics
• Full of activities to increase communication
• New ideas for generating insights
• Easy to read in quick bite-size sprints

The Bad

• Includes activities for post-retrospective goal setting, but neglects to give ideas for achieving/enforcing them
• Very thin on outlining why we have retrospectives (40 pages)
• A few activities are better suited for elementary children than adults
• Should have been renamed – The Ultimate Retrospective Activity Handbook

Every team can find this book a great resource as it is chalked full of new ideas for keeping your retrospectives fresh and on topic. If you are still not convinced, the authors did a recorded Google TechTalk which can give you a good feel for the book.

Agile Retrospectives: Making Good Teams Great

Notice: All reviews on codesqueeze are not paid nor are traded for services. These reviews are shared so you may save time in your quest for better tools.

Obfuscating code is important when attempting to keep your implementations safe, but done carelessly it can cause you business. While there are many obfuscation products for Java and .NET, there will always be industry leaders such as PreEmptive and Spices. Problems can occur when multiple components are obfuscated with the same products or same settings.

On a recent project, I had referenced a 3rd party component for PDF generation. When I attempted to add a spell-checking component from another vendor, *POOF*, everything went up in smoke. I could not shake a compile error complaining about ambiguous class names. Using Reflector I loaded up both 3rd party assemblies and found the following:

Careless obfuscation can create conflicting type names

I am protecting the guilty by blurring out the assembly names, but what is visible is the fact that both assemblies created non-unique namespaces and class names. This ambiguity created a deadlock of references and the possibilities were:

1. Get one of the vendors to get me a new build ASAP
2. Delay purchasing either component until a suitable replacement was found

Thankfully, this story ends happily and one vendor immediately responded to my email by fixing the issue and sending me a specialized build. The troublesome obfuscated classes had been moved into proper namespaces thus removing the ambiguity.

Compile errors are a bad first impression when attempting to make a sell. Bad obfuscation can cause problems that you may not have foreseen in testing. Test your assemblies in a number of scenarios to ensure they play nice with others and under different security contexts.

Happy Coding!