Local subversion practices SWOT analysis outcomes…

I thought I might take a few minutes to share with the community the outcomes of a SWOT (strengths, weaknesses, opportunities, and threats) analysis of IU’s local practices around building and maintaining our customized build of Sakai: Oncourse. We gathered all of the developers in a room for 90 minutes and outlined three different methodologies for implementing local builds of Sakai:

  1. Traditional / Legacy Overlay – This is the model we have been using for thee+ years and involves a set of files which are copied over the top of Sakai generic files (i.e. overlayed). This process served us well when we had fewer customizations and we had a smaller development team.
  2. Vendor Drop – this method, I believe, is well known both within the subversion and Sakai communities. It is a complete source tree with both customizations and generic code; i.e. a complete build.
  3. Patch Overlay – this variation of #1 uses patch files instead of complete files to maintain customizations.

The team of developers were asked by the facilitator (i.e. me) to break into teams of two and produce strengths and weaknesses for each proposed solution. We chose not to focus on opportunities or threats given the short amount of time available for the session and the domain subject may not be the best for such categorizations. The teams spent fifteen minutes working through their strengths and weaknesses and then we started recording the outcomes on the white board. What happened next was interesting — there was very little disagreement about the particular strengths or weaknesses of a given solution — there was mostly consensus. I am including the outcomes for your review:

  1. Traditional / Legacy Overlay
    1. S+ Easy to identify changed files
    2. S+ Already exists – a norm
    3. S+ Supports smaller scope
    4. W- Version control is difficult (i.e. practice vs. staging)
    5. W- Maintenance (merges, regressions)
    6. W- Training
    7. W- Requires custom build script
    8. W- Hard to share and collaborate with Sakai community
    9. W- Overlay build script is not version controlled – cannot predictably produce previous builds.
  2. Vendor Drop
    1. S+ Simple check-in, check-out, commits
    2. S+ Community support, widely adopted
    3. S+ Easy to run on developer workstations, easier training
    4. S+ Innovation is occurring around this practice in the subversion community; more standardized solution.
    5. S+ Easier debugging of code
    6. S+ Maintains source history lineage
    7. S+ Can reliable build previous production builds from source
    8. W- More overhead to find changes
    9. W- Increased merge skills for developers
  3. Patch Overlay
    1. S+ Easy to find changes
    2. W- Readability of patch files
    3. W- Custom build script required
    4. W- Training / developer workflow difficulties
    5. W- Harder to share with Sakai community
    6. W- Patches are brittle

We talked through each strength and weakness so that there was consensus for each analysis of the solutions. When we had the board filled with all of the outcomes, I then asked the team if there were any high level patterns they could identify. Immediately, they asked for solution #3 to be removed from the list as it clearly had too many weaknesses and few strengths. The next ten minutes were spent reviewing the outcomes for solutions #1 and #2. We then went around the table and each individual declared which solution they preferred when presented with all of the facts. Surprisingly, we had a unanimous vote for solution #2, Vendor Drop.

After the vote I asked the team to provide feedback on the process. The following statements were made:

  1. W- More preparation time would have been nice – to better understand the intricacies of each solution before being asked to analyze them.
  2. W- More context provided by the facilitator for Opportunities and Threats (i.e. the “OT” in “SWOT”).
  3. S+ The amount of consensus achieved in a very short amount of time.
  4. S+ Separation of the emotions surrounding the various solutions; allowing the developers to be more objective in their analysis.
  5. S+ Avoided the expected 90 minutes of “tail chasing” with no particular outcomes.

So where do we go from here? Ryan Lowe volunteered to form and lead a group of developers that will present a migration plan at our team meeting in one week. In retrospect, my first “official” SWOT meeting was a success and very effective in achieving our goals of simplifying the the processes of managing our local build of Sakai. The developers made this decision on their own and now have complete ownership of it. I also pointed out to the team that the quality of the analysis was very high; i.e. even if they had four hours or an entire day, would depth or breadth of the analysis be fundamentally higher? If you have not read blink by Malcom Gladwell, I would highly recommend it. The trick is knowing what you know. 🙂 I look forward to my next SWOT analysis. 🙂 Best, L

White board contents

1 Comment

Filed under Education, Sakai

One response to “Local subversion practices SWOT analysis outcomes…

  1. Peter Mann

    Hi Lance,

    Very interesting experience and reflections. I’ll attempt a similar SWOT analysis and will share the results with you. See you in IN soon.

    Best,
    Peter

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s