Summary
Some notes of my own, and some collected from other attendees.

1. Most people have been trained to believe they can spend freely without risks or consequences. So in most software development organizations, discussions of technical debt and risk management are seen as annoying and "negative thinking." We need to change this. For risk, putting risk items on the main list brings them to first-level importance. For technical debt, perhaps we need some way to quantify it so that people will take it seriously. -- Bruce
2. Interviewing must first be targeted to filter out unchangeable destructive qualities. If someone is a jerk, that's not something you can train out and it will probably result in harming or destroying your team. If someone plays well with others and improves team morale but doesn't understand a particular technology, that's something you can fix in a few weeks. -- Bruce
3. Trust the temp-to-hire system. Barry indicated that 90 days is sufficient to understand if someone is a fit to the team, and if they will fit with their personality and their technical skills. If someone is not a fit, don't be afraid to get rid of them. The perceived loss of letting someone go is far outweighed by the increased morale and productivity of the rest of the team. --Ryan
4. Gently introduce change to a team. Don't expect things to suddenly change overnight. If things still aren't changing and not a fit for you, do not be afraid to move on. --Ryan
5. Good design and practices applies to APIs, architecture, visual and usability. It is important to put effort on making what you create easy to use and to understand. During the discussions, Joe asked what products showed good design and why. It was interesting to see that not all products or software mentioned were necessarily the best, most stable, or had the most features. The products simply worked and were intuitive. This same type of attention to design detail should be applied to the code that we write, whether we write APIs, interact with the user, or display things visually. --Ryan
6. At Roundup '07, as a wet-behind-the-ears kind of programmer, I learned a ton about cool, useful techniques and technologies. After two years of banging around with them, I went back expecting the same. I was pleasantly disappointed! Instead, I came back with a little more "programming judgment" than I went in with. Learned stuff about how not to add "technical debt" to a project by being the new technologies guy. Picked up a book on a recommendation - "DDD by Eric Evans" - that's Pure Genius distilled. And then there's my new toy: Scala (which judgment tells ought not be implemented at work... just yet, anyway). Plus, all the Agile talk gave me insight into what the new Software Director is pushing for and a common language for discussing it. And the camaraderie and cooperation was out of this world. I guess that wasn't too short... Too much Good Stuff. Did I mention that our view of our application came back from CO revolutionarily better? -- Jason
7. The fun structure of an open spaces conference can be applied easily to a team or a company if management is open-minded. Lightning talks once a month are an inexpensive way to stimulate creative thinking, increase laughter, boost team morale, exponentially spread knowledge, and lure shy developers out of their shells. -- Joe Sondow
8. If you must use Swing, consider Groovy's SwingBuilder for its superior, short, declarative syntax. If you're free to try something else for your GUI, consider JavaFX or Flex. Either one can start out as a Photoshop document with well-named layers that automatically become programmatic elements ready for adding behaviors. If building a GUI from scratch, Flex currently has a smoother Matisse-like interface than JavaFX. On the other hand, JavaFX apps run on a JVM which many people already have, while a Flex desktop app requires Adobe Air which is less ubiquitous. These are not deep revelations, but damn useful. -- Joe Sondow
9. After each release, doing a retrospective helps the team learn recent lessons together, and spreads out the knowledge of how the evolving system works today. The retrospective can cover interesting new features, code changes, and challenges met. -- Joe Sondow
10. Given a group of enthusiastic, knowledgeable, motivated people, a world class conference can seemingly appear out of the ether, have lasting effects and rejuvenate the participants beyond all expectations; even when you do it with Geeks. -- Andrew Harmel-Law
11. Regardless of how well we understand that defects are best and most cheaply found through the review process, for some reason companies still can't seem to justify doing reviews. -- Bruce

Talk Back!

Have an opinion? Readers have already posted 7 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.