Life, Teams, and Software Engineering

Month: March 2010

Giving Back to the Professional Community

Inspiration


My brain has had a month or so to think about Jean Tabaka‘s article, Countdown to Agility: 10 Characteristics of an Agile Organization, in the November/December 2009 issue of Better Software Magazine (I only read it last month).  This, combined with my recent exposure to talk of Coding Dojos, Code Retreats, and Weekend Testing in the TwitterVerse have inspired me to get my thoughts connecting these two down in writing.  Specifically I’d like to talk about #7 in the article, “Contributing to the Community and Maintaining a Profitable Company“.

A recurring theme in the article is the marriage of seemingly competing interests, Work/Life Balance and Constant Delivery, Servant and Leader, Sustainable and Successful, the list goes on.  It’s a good article, give it a read and see how your organization stacks up.  At first glance, giving back to the community seems like it will cost you while doing nothing more than generating good PR.  The article describes three communities to contribute to: the local community, the global community, and the professional community.

When you hear “giving back to the community” usually you think of community service.  Usually this happens locally and there are a lot of companies that do a fantastic job of this so I won’t harp on it.  I personally wouldn’t know where to start giving back to the global community.  Perhaps contributing to relief efforts in areas like Haiti, Chile, and Japan given the recent earthquakes?  But something I don’t hear a lot about is how organizations give back to the professional community.


Types of Events

I’m going to focus mainly on three types of events here; Code Retreats, Coding Dojos, and Weekend Testing, but anything that carries the spirit and intent of these events I feel should be handled the same by an organization.  I describe these as:

A deliberate, purposeful (i.e. goal-oriented) gathering of like-minded professionals coming together to better themselves, their craft, and each other.  

I’m going to make a few observations about these events, interpret it as you will.  All data is as of this writing (March 20, 2010). I’m going to put more focus on the US groups because I’m biased:

Coding Dojos – Map available here

  • Lots of groups in Europe and South America
  • 2 groups in Canada
  • Only 5 groups in the US 
    • Redmond (only open to Microsoft employees…)
    • University of Houston – appears to have gone dormant as of 2007
    • Oklahoma City
    • Pittsburgh Dojo – Last met Sept 2009
    • Albany, New York

Just looking at the map, the US is pretty far behind with this.

Code Retreats

  • Boulder, Colorado
  • Pittsburgh, Pennsylvania
  • Philadelphia, Pennsylvania
  • Detroit, Michigan
  • Floyd, Virginia
These are just the ones listed on their homepage as coming up.  Noticeably Pittsburgh is on both lists and noticeably this list is all US.  That’s pretty great and hopefully the list keeps growing.
Weekend Testing

4 chapters since inception in August 2009 in 
  • Chennai, India 
  • Hyderabad, India
  • Europe
  • Mumbai, India
The US is completely missing from this list.  I know we have talented testers that would love an opportunity like this to share their knowledge and expand their horizons.  I don’t know what it would take to get chapters started throughout the US, but given the structure the group has taken on, local or regional technology councils seem like they would be a good place to start.
As an Officer, why should I care?
By “officer” I mean someone holding a position of power and decision-making in an organization.  So why should you care?  Someone is bound to start one of these up in my area sometime, why should it be us?  Here are some big reasons that come to mind:
  • Your employees will get better (on their own time no less!)
  • People attending from outside see that you are supportive of your employees and their goals
  • Networks and ideas will develop between the people attending.  And we all know what comes from ideas.
  • Attendees will be more likely to consider your organization when they look for their next opportunity.
  • and perhaps more altruistically, you’ll be contributing to the advancement of the craft.  Something everyone can always benefit from.
So instead of “why should it?”, “why shouldn’t it?”.  It just means that when that next big advancement reveals itself you and yours will be ahead of the curve.
Suggestions for Implementation
So hopefully I’ve piqued your interest.  Now you ask, “how can I make it easier for everyone to get off the blocks and get one of these started?”   I’m glad you asked.  Here are some suggestions:
Do NOT
  • Force your employees to host one or more of these events.  
It may seem like a great recruiting and marketing opportunity, and it can be if approached correctly, but don’t make it your primary goal.  Pursue it with this as your end goal and it’s doomed from the onset.  These movements should be grassroots, initiated by people with a genuine desire to implement continuous learning and just get better.  You get better with practice, which is what these groups provide; an environment for software professionals to practice.
Do
  • Encourage people who wish to host events like these.
  • Remove barriers.  Make it easy for people to reserve spaces and market the events in your organization’s name.  Some lunch money wouldn’t hurt either :).
  • Provide support and resources.  
Do these things and you’re sure to see the long-term benefits I’ve described above.
What about your company?  Does it support efforts like this?  Do you have any additional suggestions for employees wanting to start one of these up?

Is tooling only for the youth?

Disclaimer: This post maybe have no basis in reality at all outside my team, it’s just a question. This post is done with information on a case study of 1.

I moved to the wide world of ANSI C++ after working in C# with the love of ReSharper for the better part of 2 years. I managed but I definitely felt the absence of the great refactoring tool that took the things that should be easy and trivial and made them so. C++ is not that way, especially with old IDEs. So I started searching this past weekend for a C++ refactoring tool that actually supported my IDE. I found one that claimed to support it, Visual Assist X, so I installed it and started playing around with it. It works pretty well for what I need it to do but I haven’t fully explored it yet.
Either way, this post isn’t about Visual Assist X. Today after I set up my keyboard shortcuts (to match ReSharper, no less) I called my team’s senior developer over and showed him what it could do.
Him: Another tool?!? *shakes head* I don’t trust tools to do much of anything. They’re just more systems with their own bugs.
Me: Yes but what they do they do well. Why not take it for what it is and accept that nothing is perfect?
Notice these are not direct quotes. I remember better what he said than my own response (mostly because I was surprised by his reaction), but that was the general nature of the conversation. He then proceeded to call me “Mr. Tool” and was quick to dismiss it. I was a bit confused by this, but didn’t think much of it at the time. I had work to do so I went on my way.
Now, sitting in my living room catching up on back episodes of Legend of the Seeker something creeps up from the back of my mind. Do I really rely on that many tools? Let’s list them out:

Development:

  1. Visual Studio
  2. CppUnit (is that really a “tool”?)
  3. Rational PureCoverage for capturing code coverage
  4. Hudson for Continuous Integration
  5. CppDepend, CCCC, CppCheck, SourceMonitor for various static analysis (some do things better/more simply than others)
  6. And now Visual Assist X for refactoring support.

Process:

  1. Jira + GreenHopper
  2. Confluence
  3. Crucible
  4. Fisheye
    I don’t think this list is unreasonable at all. OK, so maybe the static analysis tools are a bit excessive but I like data, especially when it costs me next to nothing to get it through Continuous Integration.

    Let’s look back to September 2008 when I joined the team. They were using exactly ONE of these tools, Visual Studio. No unit testing, no continuous integration, no process support tools, certainly no automated testing, and worst of all no feedback mechanisms of any kind until a project ended and you handed it over to the customer to say “I hope this is what you wanted”.

    Flash to today. We have 20+ configurations in Hudson, our latest project has 90%+ unit test coverage at all times, our system testing is as automated as it can be so our test team isn’t overwhelmed, all our documentation is maintained in Confluence, and all our issues and tasks are tracked in Jira.

    I feel like each of the tools listed above plays an integral part in my day-to-day work as a developer. Obviously as developers we spend less time in the management systems and use very limited features of them, but does that make them any less important? No. If management can just jump out to Jira to check our status or out to Confluence to answer their question, that’s one less thing they had to bother me or my team about. It makes me happy and I don’t even know it, and I’m sure they appreciate it too.

    Now I finally get to the question. Is the reason for his reaction a generational thing or am I completely off base? Are the youth more likely to find a tool-based solution to a pain point while the more seasoned have just learned to deal with it?

    Then there’s the other possibility, am I over-reliant on tools? Maybe I could simplify, but do I understand how they work, their purpose? Absolutely. I know what the scope of their functionality is, how they do what they do, what they’re NOT meant to do, and how to bend them to my will within the constraints of the tool. Each one of them adds value and there are only 3 of them that any developer on the team really has to know or use; Visual Studio, CppUnit, and PureCoverage…I take that back, PureCoverage isn’t necessary for them to understand, they just need to have it installed since every time they run a build it runs the unit tests with coverage. They could completely ignore the results and I wouldn’t know the difference.

    What do you think? I’m sure there are exceptions as there are with any rule, but are the youth more likely to blaze new trails?

    Copyright © 2017 Life, Teams, and Software Engineering

    Theme by Anders NorenUp ↑