roy

One of the great assets of having such a huge community like the one around MindTouch are its participants. When I started, I only thought code contributions were important from developers. To be honest, we haven't received much (if any) patches to the core product - what we have seen are people writing a ton of apps on our platform, instead. We receive a steady influx of bug reports from community members which keeps us quite busy.

In the early days, when our product's direction was simpler ("it's the best wiki in the world"), we also tapped our community for feature suggestions. Constantly interacting in IRC & the forums was critical in helping us stay ahead of the curve - the technical folks always seems to anticipate the needs pretty well.

When we made the switch over to a commercial version, we lost that. It may have also been the fact that we had reached the limit of features we wanted to add to the wiki (at some point, the law of diminishing returns makes each feature useful to less and less of your target market).

At that time, we worked on a lot of technical features with little community feedback.

Recently, I have been constantly pushing the engineering team to write functional specs. Functional specs are important because they are easily understood by a large group of people, which means you can open up a discussion with non-technical users as well. These non-technical users quite often have the most insight into what makes a feature fantastic.

Our first functional spec was for the drafts service, which was a great first case. While it was still technical (we had actually hammered out the use cases earlier on, so they didn't need a discussion), it still provided to be a great reference point during the development. It also helped people understand exactly what we were trying to deliver.

The second functional spec (that I've been driving) is the attachment reservation (file check-in/check-out) feature we are developing. I have to say that the activity on that functional specification has been most promising. The comment thread has been incredibly informative in refining the direction of the feature; even little suggestions like "adminstrators should be able to lift reservations" which were missed on the first pass.

And the best part? The iterations around functional specifications are far cheaper than "trying it in code." If you're running any type of software shop, you really want cream-of-the-crop engineers, and their price per hour ain't cheap.

One process I'm implementing at MindTouch to return product development back to a bottoms-up approach is to force engineers to write functional specifications and present them at our weekly engineering meetings. These give time to gather feedback from the rest of the engineers (who shouldn't be discounted - they have seen over two years of active MindTouch development, and they interact with MindTouch community members constantly).

Without a strong spec in place, engineers can oftentimes overengineer solutions that don't solve any problems - the thing was simply engineered. Talking it through in committee and gathering feedback clarifies where we need to end up. I originally though technical specifications solved this problem of engineering development creep, but unless the technical spec had functional use cases to keep it contained, things could quickly spiral out of control.

That's not to say that I don't think paying down technical debt with code clean-ups isn't important, but they must be accompanied with some commercial end-goal in mind. In the attachment reservation implementation, we'll need to clean up a chunk of the front-end code (long overdue from legacy days) ... but it's for a commercial purpose.

So to get back to the point: the attachment reservation spec is awesome (check it out!). I hope the functional spec process sticks!