Learning Software the Fast Way

June 8, 2009

Basic Concept:

The fastest way to learn a software technology (programming language, tool, or architecture) is to work on real life problems with reference material and expert advice available quickly when needed. Peer review of open source code and documentation can give a team of new developers exactly the setting they need for rapid learning. Source review is a safe way to multiply the number of developers actively participating in an open source project without demanding the level of competence that must be required for source commit authority.


Form collaborative teams of developers who want to learn a specific technology. Choose an open source project that uses the technology. With a little guidance from people already in the open source project and a lot of mutual aid within the learning team, the learners can review source changes and create bug fixes. The open source project will gain by dramatically increasing the number of developer who are familiar with the inner workings of the project. The learners will gain a gut feel for how the technology really works in a live context.

Of course, this approach may not expose the learners to all features of the technology as effectively as tutorial material that is designed to be complete. A student who needs deeper knowledge should bolster participation in the learning team with independant study or an academic course. However, participation in the learning team alone can give an experienced developer enough knowledge and confidence to use the technology in projects without the learning team. The team may choose to combine open source participation with tutorial studies.


There isn’t a reference implementation for the collaborative learning teams, so you’re free to invent your own process. The key components, as I see it, are:

  • Learning Goals: Identify the technologies to learn and specific skills to gain using the technologies. Establish criteria for determining when a learner has met the goals.
  • Guidance by the Open Source Project: Identify an open source project that uses the technology. Establish agreement for the project people to guide the learning team in identifying source code or documentation to review that will advance the learning goals.
  • Source Review Process: The key learning activity is review of source code and documentation for bugs, errors, lack of clarity, and potential enhancements. Establish a clear process for tracking issues found by reviewers and giving feedback to the reviewers about the findings. Perhaps the learning team should evaluate their findings among themselves before reporting the issues to the open source project.

What’s Next?

Let’s discuss the concept.

  • Do you agree that guided source review could greatly accelerate learning software technologies?
  • Do you agree that learning teams focused on open source projects could dramatically multiply the number of developers capable of contributing?
  • Are there open source projects willing to sponsor learning teams?
  • Have you used a collaborative development environment that would fit well?
  • What’s missing, or what could make this work much better?
  • What do you suggest for the next steps?

If anybody wants to take this idea and run with it, or wants to discuss it elsewhere, let me know. If you do, I’d appreciate a link back to this blog and/or a comment posted here with a link to your discussion.

How Open Source Isn’t Open, and What to Do About It

March 12, 2009

The Problem:

Open source development can’t be completely open. Sure, you can read all the code and docs for any good open source project. But the way you really learn a code base is by changing the source and making sure the changes work. Of course, nobody running a successful open source project can let just anybody out there in the community get in and mess with the code. So there’s a closed circle of trusted committers who do the real work of developing the project, while everybody else watches and comments. Getting to know the code well enough to become a trusted committer takes more effort than most members of the community can afford, so the circle of people who understand the code usually remains limited to small number of developers who are paid full time by an enterprise that has a vested economic interest in the project.

Suppose a developer wants to learn about the internals of an open source project, but doesn’t have much time to give. Wouldn’t it be great if there was a safe way for anybody interested the source to spend just a few hours digging into the code, and still make a genuine contribution to improving the project?

The Solution:

Code inspection can make it happen. For little effort and no money, any open source project can publish the diffs in source code changes and invite the community at large to inspect the code for defects and points of confusion. No vetting is necessary, since the inspectors won’t commit anything. The immediate benefit will be finding bugs that tests might miss. A huge secondary benefit will be increasing the number of people who understand the code and who can contribute to the project. By adding code inspection to the existing development process as an optional volunteer activity, the core developers can continue as before without necessarily waiting for their changes to be inspected, while the community at large gains a genuine sense of ownership by contributing significant value through inspection as time permits.

The Tool:

Code Collaborator by Smart Bear Software, winner of the 2008 Jolt award for Collaboration Tools, is free for use by open source projects. No, I don’t work for Smart Bear. I just heard about their product, read their free book The Best Kept Secrets of Peer Code Review, and have been looking for a place to use it ever since. I learn best by doing work that has real world value, not just academic tutorials. Code Collaborator supports inspection of any kind of source, provided it’s in text form and diffs between versions can be generated. It makes sense to inspect and improve source comments, specifications, and user documentation, not only the code. It makes sense to use inspection to identify and clarify points of confusion, not only actual defects.

Or Not The Tool:

Suppose you don’t want to use Code Collaborator. Maybe you work with closed source and don’t want to pay, or maybe your potential inspectors won’t learn to use the tool. Then find another way to do code inspections. Make your own lightweight process. There are basically two ways to find software defects. Run it or read it. You know you’re going to run it with tests and in production, so why not read it also? You will discover defects, but even if you didn’t, the benefits are worth the effort.

  • Inspectors get cross trained, so your organization is more robust.
  • Inspectors learn more coding techniques.
  • Code that’s correct, but hard to understand, is identified and
    explained or simplified.

Read the free book from Smart Bear. It’s an eye opener.