Summary
Some notes of my own, and some collected from other attendees.
Advertisement
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
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
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
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
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
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
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
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
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
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
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
> 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."
I think this is very true. After the recent events world economy, I started wondering if this wasn't a more general problem and hoping that it might start to change how people thought about those who identify risk.
Unfortunately, I haven't yet seen any such shift. For example, on a discussion thread, I pointed out that the cloud, while offering some great opportunities also adds risks and problems. Based on the responses to my comments, they seemed to make a people angry and I received very little in the way of support. It was if people couldn't understand the difference between, "don't use the cloud" and "be careful about how you use the cloud". I've also not seen any shift in my own organization. Perhaps this is a result of being overly risk-adverse. Pointing out a risk prevents projects from moving forward so no one is willing to identify risks. That is, if I present an idea and mention the risks, and someone else presents an idea as having no risks, then their idea wins, even if it's risk is higher and/or is just a bad idea.
One of the things that I've read lately is that financial groups are making a conscious effort to listen to contrarian viewpoints and include them in decisions. Whether that happens remains to be seen but I feel that we need some sort of similar push in the IT industry.
The fact that you say that pointing out a risk keeps a project from moving forward is very telling. It's a flaw in our culture -- instead, we should be saying "hey, unless we know what the risks are we can't move forward."
> The fact that you say that pointing out a risk keeps a > project from moving forward is very telling. It's a flaw > in our culture -- instead, we should be saying "hey, > unless we know what the risks are we can't move forward."
It's actually even worse the more I think about it. I get the distinct feeling that people who point out risks are unwelcome because they make it harder to duck responsibility. If something bad happens, a pretty good excuse is that no one thought thought of that possibility. We're only human and can't be expected to be flawless. But if someone points out a risk early on, you can't claim that no one had thought of it. We'll you can but it's a lie, and one you can get caught in. The Bush administration was really big on this. I hate to get political but I'm hoping that the last administration set a bad example for everyone and that we are entering a new phase of pragmatism.
> > The fact that you say that pointing out a risk keeps a > > project from moving forward is very telling. It's a > flaw > > in our culture -- instead, we should be saying "hey, > > unless we know what the risks are we can't move > forward." > > It's actually even worse the more I think about it. I get > the distinct feeling that people who point out risks are > unwelcome because they make it harder to duck > responsibility.
I don't claim to understand people's motivations, but I tend to be one of those who points out risks and potential problems when they come up. Generally the development class will understand and share my concerns, while the leadership class won't want to hear about it. In particular, I have had some who don't want to hear about problems unless I have solutions readily at hand. How are we supposed to address the big problems if we are forced to keep them to ourselves?
> I don't claim to understand people's motivations, but I > tend to be one of those who points out risks and potential > problems when they come up. Generally the development > class will understand and share my concerns, while the > leadership class won't want to hear about it. In > particular, I have had some who don't want to hear about > problems unless I have solutions readily at hand. How are > we supposed to address the big problems if we are forced > to keep them to ourselves?
That's one of those specious arguments that people love to use. Often I find that they don't really want to hear the solution either. It's just a technique to make people shut-up and put them in their place.
> I don't claim to understand people's motivations, but I > tend to be one of those who points out risks and potential > problems when they come up. Generally the development > class will understand and share my concerns, while the > leadership class won't want to hear about it. In > particular, I have had some who don't want to hear about > problems unless I have solutions readily at hand. How are > we supposed to address the big problems if we are forced > to keep them to ourselves?
First of all if a company has a QM then reporting risks is part of the project plan. If it lacks a QM then it obviously has an even bigger problem.
Secondly whether or not the leadership class wants to listen it has to be informed and this has to be documented - an e-mail often suffices. So it is up to them to manage or ignore the issue but they can't blame you or anyone of the development staff to have overlooked potential risks. You can't do much more unless you become a manager yourself.
Previous Topic
