The Artima Developer Community
Sponsored Link

Weblogs Forum
What I learned at Java Posse Roundup '09

7 replies on 1 page. Most recent reply: Apr 19, 2009 5:36 PM by bob Pasker

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 7 replies on 1 page
Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

What I learned at Java Posse Roundup '09 (View in Weblogs)
Posted: Apr 9, 2009 11:36 AM
Reply to this message Reply
Summary
Some notes of my own, and some collected from other attendees.
Advertisement
  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


James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What I learned at Java Posse Roundup '09 Posted: Apr 10, 2009 8:15 AM
Reply to this message Reply
> 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.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: What I learned at Java Posse Roundup '09 Posted: Apr 10, 2009 12:59 PM
Reply to this message Reply
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."

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What I learned at Java Posse Roundup '09 Posted: Apr 10, 2009 2:27 PM
Reply to this message Reply
> 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.

Gary Duzan

Posts: 5
Nickname: gduzan
Registered: Apr, 2009

Re: What I learned at Java Posse Roundup '09 Posted: Apr 14, 2009 12:21 PM
Reply to this message Reply
> > 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?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What I learned at Java Posse Roundup '09 Posted: Apr 14, 2009 12:33 PM
Reply to this message Reply
> 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.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: What I learned at Java Posse Roundup '09 Posted: Apr 15, 2009 7:08 AM
Reply to this message Reply
> 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.

bob Pasker

Posts: 1
Nickname: rbpasker
Registered: Apr, 2009

Re: What I learned at Java Posse Roundup '09 Posted: Apr 19, 2009 5:36 PM
Reply to this message Reply
Risk is something that needs to be assessed so that it can be factored into the development process. Here's how to do it

http://blog.pasker.net/2007/08/21/reducing-risk-in-software-development/

Flat View: This topic has 7 replies on 1 page
Topic: Stupid datetime testing Previous Topic   Next Topic Topic: What Do You Consider

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use