I think it’s important to measure the impact of our improvements. I want to know: are we moving faster? Is product quality flourishing? Can we say so quantitatively? The last bit has been the most elusive. It’s like measuring how useful a painting is!

Still, here are some measures which we hope will eventually show how much the improvements are or are not helping. Right now we’re just establishing baseline data.

The red line in the graph represents legacy front-end code that will eventually disappear. The green line is new code, but it really doesn’t matter.

From the chart data, we can say the following by measuring deltas between points: the most dramatic change in Struts/jsp LOC was 4380, for the time period ending Aug 2010.  The most dramatic change in SpringMVC/ftl LOC was 3665, for the time period ending Sep 2010.

Assumptions:

• these data are not useful for estimating speed of future refactoring work
• all acceptance tests pass in refactored areas
• look & feel of refactored areas is acceptable

The 2nd & third bullets are a bit vague. To address this shortfall, we’ll measure the following aspects of quality:

1. Time spent modifying CreateSavingsAccountTest.
2. Number of issues (regressions) caught during CSS walk through.
3. Number of layout or functional bugs logged during testing phase (missed during walk through).
4. Time spent by QA manually testing the feature, including logging issues and retesting bugs fixes.

Finally, developers should know if things are better. This is the most qualitative and possibly the most important “measure”! Certainly, for the migration of our codebase from svn to git, it was the only measure we used, and it was enough.

Thoughts/comments/feedback are appreciated. I’d rather have some kind of simpler measure, like “x increased by 250%”. Do you know of any more effective (and hopefully simpler) means of measuring development speed?

I used gnuplot to generate the graph. Here’s the source.

Here are some example tasks for the i18n champion:

• Make sure messages in Mifos are translatable.
• Document messages and resolve issues mentioned on our Translator Helpdesk.
• Hang out in #mediawiki-i18n (an IRC channel on Freenode), answer Mifos questions when they come up, or add them to the Translator Helpdesk.
• Work on specific i18n issues: MIFOS-3859, MIFOS-3821, MIFOS-2018 and others.
• Improve and refine the Mifos i18n/L10n guide.

See also: #Mifos, #microfinancing and #Wikimedia

Update

A day after I sent out this call for help we got two volunteers! Thank you, Stanley Kwok and Jasmine Sandhu!

Since we used FLOSS Manuals to write our manual, it’s easy to generate an ebook using Objavi. Here’s the Mifos Manual as an ebook. Looks pretty good on the iPhone (lately I’ve been using “Stanza”). Probably looks even better on a Nook, Kindle, or iPad.

Our corner of the Grameen Foundation focusing on Technology for Microfinance has a lot to learn from OpenNMS! They’re also FLOSS, and they’re profitable.

I talked with Tarus the other day. Turns out he’s a really cool guy. I’ve been following his blog closely for quite a while now, so I was thrilled with the chance to pick his brain. The point of the call was to find out why and how they run their developer summits: in-person meetings where coding, alignment, teambuilding and planning are plentiful. OpenNMS hosts these yearly, and we’d like to do them for Mifos.

We talked for a while, so I’ll summarize. I’ll cover the dev summit stuff first, then more about FLOSS business.

Adam: what instigated the first summit?

Tarus: I live on a farm in the middle of NC, wanted to get in touch with other devs. I invited them to hang out at my place and code for a week. The result was camaraderie and commonality of purpose. In other words: the hard stuff. We also got a lot of useful coding done. There were only 5 people, yet it was an awesome time.

A: How do you think things will be different if you didn’t have these summits

T: we had to cancel last year’s, and we felt the pain. We missed each other. We usually have dev tasks that are especially suited to summits that we didn’t do.

A: can anyone come?

T: yes. We sponsor active contributors. Full-time paid employees are pretty much required to go. Others must pay $1400 (includes room + board). This is modeled after debconf ( http://debconf.org ).

A: who comes?

T: 1/3 full-timers, 1/3 sponsored volunteers, 1/3 folks who pay their own way. Even with the folks who pay, dev summits are expensive and can run $20-$30k.

A: what’s the format?

T: loose/barcamp/vague. This works much better for us than a dictated organized agenda

A: What are your definitions of “success” for a summit? How do you know when you’ve had a successful summit?

T: we don’t really have a measure, but the value is apparent from the team cohesiveness, fun had, code produced, and productivity following the summits.

A: can I come?

T: yep

A: what do I need to do to run a successful summit?

T: plan it well. Make it fun. Buy food. Have someone go onsite and set up logistics: rooms, wifi, whiteboards, projectors, etc. Do stuff together. Discourage newbies (they need to pay to attend): don’t make it a training session: make it a *developer* summit. Publish prereqs: compile the code, run tests, study the schema, have your laptop ready, etc.

Other stuff:

A: where are your devs?

T: global.

A: how do you reward volunteers and retain contributors?

T: LOTS of ways! “order of the X polo”: exclusive group of contributors are in the “order of the green polo”, these folks are the steering committee. OpenNMS is business driven, but the OGP drives the tech. They stick around because they are invested and we value what they say. They’re the experts. OpenNMS Group sells services, not software: training, consulting, installation, custom dev. Volunteers and contributors are invited to (and do!) do the cool stuff, the fun stuff, the most important stuff. We guarantee the code will not suck, and it will always be Free (as in freedom). also see “order of the blue polo”: that’s the one you should sign up for, Adam!

A: will do. Can you say more about what custom development you’ll have to do?

T: yes, but not just anything. Ex: someone wanted RT integration. Instead, we built a generic event-based framework and allowed them to hook into it. I don’t sell “custom dev” to a customer, I make them *sponsors* of features that make it into OpenNMS. Salespeople must have technical knowledge to make this work. The custom features aren’t what make them competitive anyway, it’s their business strategy, their processes, their people. We also sell commercial licenses for OEM arrangements. They pay for (us to do) custom dev, and we get the code, too.

I’ll be there, too!

Thanks to Adam Feuer for encouraging me to approach Tarus/OpenNMS.

We’ll have a video feed going. I’ll be wearing my track suit.

Check out our coordination wiki page and stop by our IRC channel if you’d like to join in! If you’ve ever edited text on a wiki, are brave enough to learn how, or just want to see me in a track suit, come on by.

I suppose I should explain the title of this post. If we can establish a framework for software development on Mifos like we’re running this sprint, we can break Brooks’s law. Why not? The Ksplice folks did it, so we can too!

Why is performance so bad? Why does the server keep failing? Sun and CollabNet have been responsive (thank you Sonya and Eric!) but mainly all we hear is “we’re working on it”.

The outages are costing us. If service doesn’t improve, we need to move to another provider. SourceForge sounds hopeful, especially since we can directly migrate over our Subversion repository and, eventually, switch to a dVCS like Mercurial.

If you’re an eligible and interested student, check out our ideas page, hop on IRC during US/Pacific business hours, ask away on the mailing list, download the code, try building it, etc. and we’ll get you signed up!