Radyology

Why Open Source Succeeds Where Offshore Fails

The Agile practice of keeping the whole team together has many benefits, and many people consider it essential part of any software development effort. But if this practice is so critical, how is it that open source projects, whose team members may never even meet each other in person, seem to be able to deliver working software? Through my experience as an agile coach, open source developer, and participant in many multi-location projects, I've developed some theories over the last few years that may explain this difference.

I haven't ever met a developer working on an open source project that didn't use the tool themselves. Open source projects all have an onsite customer...themselves. This means that the communication that does occur between developers is usually more of a debate about what the software should do, rather than simply a unidirectional communication of requirements. This has many benefits, not the least of which is the fostering of bi-directional communication. If a commercial developer misunderstands a requirement, and the effort required to clarify it is too high, they might say "well, that seems silly, but I guess it's what they want" and implement it incorrectly. If an open source developer sees a similar request on the project mailing list, a lively argument will ensue, usually resulting in a clarification or adjustment of the requirement that makes the product better.

A typical open source project is, by and large, a leisure activity. The goal is to have fun and make useful software, not turn a profit. This simplifies the constraints considerably. Successful commercial projects must serve two masters. Developing a useful product is not good enough. You must have a business plan that lets you get the most out of your investment, which can be considerable. Successful companies must find ways to keep these goals aligned, but open source projects don't need to worry about it. If the developers make a useful tool, they feel good about their work. Whether or not that product can be monetized is irrelevant.

Open source projects are self organizing. Remember, the people working on it are doing it for fun. Granted, there are a few lucky souls who are paid to work on open source projects full time, but most of these developers have attained this positions by contributing hours of their own time first. So just as the members of community softball team are likely to have a few things in common and be able to communicate well (especially about softball), the developers on an open source project tend to have a lot in common. The only thing keeping them on the project is the camaraderie and peer recognition they get, so if they don't work well with the team, they just stop working.

All of this means that that the barriers to effective offsite communication are much lower for open source teams. When an open source developer sends an email to another about the XYZ widget in module ABC needing to be cleaned up, the full meaning of that message is much more likely to be understood than a similar email sent from one commercial developer to another. That's because the open source developers are more likely to read the same blogs, like the same development tools, and (most importantly) have a common understanding of the value that their project delivers. This easy, cheap, but effective focus on value delivered is what keeps open source projects a step ahead of their commercial counterparts when it comes of offshore development: Commercial developers have to be paid to care, open source developers would have to be paid not to care.

Speaking at Agile 2008

My proposal for Agile 2008 on Continuous Testing was accepted! Huzzah!

For all of you attending the conference, it will be at Sheraton Hall C, on Tuesday at 10:45-12:15.

Pascal's Wager for Software Maintenance

1. If you write clean code, and the project gets canceled, you've lost nothing
2. If you hack out dirty code, and the project gets canceled, you've lost nothing (aside from your professional self-respect, of course).
3. If you write clean code, and the project gets extended, then you get to work in code bliss.
4. If you hack out dirty code, and the project gets extended, then you'll be doomed to code hell for all eternity.

Dvorak Benchmark Redux

45 wpm with 4.1% accuracy

CITCON Rocks!

Just got back from CITCON Denver 2008, and it was fantastic. Two thumbs way up for the best 1 day conference I've ever been to. In fact, for the price (free), I'd say it rivals any other conference I've been to in the last year. Well worth the time and minimal expense, and I'll be pulling out all the stops to make it again next year.

In one of the open spaces, I was able to do a (very) abridged version of the presentation on Infinitest that I hope to give at Agile 2008. There's still time to offer reviews and feedback, so if you're interested in Continuous Testing, it's not too late to recommend its inclusion in the '08 program.

Infinitest v3 Released!

After months of work (and neglecting my blog) Infinitest 3 is finally ready for prime-time. There's been a lot of great improvements in this version, including:

• Automatic sorting of errors by point of failure, rather than by test
  
• New 'zero configuration' launcher
  
• Significantly improved test runner performance
  
• Regex-based filtering for tests
  
• Updated status and error messages
  

I'm really excited about this new version and I'm looking forward to presenting it at CITCON this week. So, if you're going to be there, look me up.

Continuous Integration Is A Hack

A recent discussion at SD West, revolving around Agile certification and the need for "Agility" metrics, ended up with me standing on a chair and ranting at the entire audience...

(Sigh)

When will I learn?

CI is one of many useful practices that Agile developers employ today, but fundamentally, it is a hack. That's because although it's very useful to know that I've introduced a bug 20 minutes after creating it, what I really want is to know the very second that I type the offending line in my editor. CI is just the best that we can do right now, given the technology that is at our disposal.

And that is why I will continue to rant and rail against any "Agile" certification that focuses on practices. As if checking off a list of best practices was the best way to learn and adapt. I'm sure at some point in the future, we will move beyond the need for CI, to something that solves the core problem more effectively. But an "Agile" certification that mandated CI hinders that search, because by adapting to a better approach, you no longer meet the standards of the certification. Inhibiting the desire to adapt and change is the very anthesis of Agile.

Agility is a set of values and principles...and no more. Practices depend on technology and technique, which can (and should) be constantly evolving. Values, on the other hand, address the fundamental issues raised when humans work together to create something, and that is truly what makes Agility worthwhile.

What does a light bulb teach us about Test Driven Development?

Electrical Engineering is a hobby of mine. Electronic components fascinate me, and I usually have a little EE side project going on just to satisfy my solder-lust.

Lately, I've been watching some of the MIT open courseware and one particular class has been getting most of my attention, EE 6.002: Circuits and Electronics.

One of the topics covered in this class is a EE principle known as the Lumped Circuit Abstraction. What the LCA does is assume that the current into a component, less the current out, is equal to zero. This makes modern electronics possible, because without it, you're left only with Maxwell's Equations to describe the flow of electricity. Trying to compute the flux over something as simple as a light bulb would be extraordinarily complex, even for the most accomplished engineer. The LCA simplifies Maxwell's equations down to a small set of laws, that anyone with a high school math education can apply.

Of course, the LCA does have a drawback. It assumes certain things that may or may not be true for a given object. In order to gain this simplicity, electrical engineers have to restrict their work to discreet components that fit neatly within the constraints of the LCA. Resistors, capacitors, transistors, diodes...all these components can be treated as a black box, and used to build systems that do interesting things.

Could EE's use components that don't fit in the LCA? Sure. And I would bet that in some very rare cases, they do. But these engineers have recognized that keeping system designs simple almost universally outweighs the benefits of making them more efficient, compact, cheaper to build, or whatever else a non-discreet component would buy them...because the cost of trying to design a system using only Maxwell's equations is enormous.

So what does this have to do with Test Driven Development? Often, you'll hear the objection that TDD is too hard because not all software is easy to automatically test. That's true. But at the same time, we have to make sure our software works before we ship it out the door. While an untestable component may be cheap to write, the net cost of creating and maintaining it is much higher.

So what do we do? The LCA makes it pretty clear. Don't build components that cannot be automatically tested. At first, this can seem pretty restrictive. However, experienced Test Driven developers will tell you that sticking to this rule actually helps improve their designs, because they're more naturally decoupled and cohesive.

So I think if you're objecting to Test Driven Development because you can't find a way to test the software you're writing, you've got it all backwards. I would propose that you're building the wrong components to solve the problem, and that you should consider using something that's testable. At a minimum, you'll eliminate the test/fix/test cycle that's likely occurring at the end of all your release cycles. You may actually wind up with a better design.

Dvorak Benchmark

Using the Dvorak layout...

After 5 hours and 18 minutes of total practice, 26 WPM with a 3% error rate. I haven't learned all the keys yet (about half), so this benchmark is taken using a subset. Still...I'm happy with my progress so far.

Dvorak benchmark

So, when re-typing "Common Sense" by Thomas Paine, using a QWERTY layout, I can type 41 words per minute with an error rate of 5.7%.

Lets see how much I can improve on that by switching to Dvorak.