SwirrlSpeak

I already covered why spreadsheets are a poor choice for collaborative work, in The curse of the spreadsheet, back in Feburary. So what about the other end of the spectrum: bespoke designed, database-backed applications?

In last week’s blog post on Wikinomics I mentioned a new interpretation of Coase’s law:

...companies should shrink until the cost of performing an action internally no longer exceeds performing it externally. Why develop software internally, or design bespoke software when you can buy off-the-shelf products which often perform the function just as well (if not better), at a fraction of the cost?

Of course, sometimes people have specific or complex requirements where no good off-the-shelf product exists, or they need to integrate a bunch of standard systems together in a new way: in those cases developing custom software is the only option. But a lot of re-inventing of the wheel happens.

Designing an application to solve a specific problem is an iterative process – it is very rare that an implementation of the initial design is a perfect fit. Something always gets lost in translation from the domain experts’ explanation of the requirements, so frequent intervention is required to ensure that things remain on track. In fact, people often don’t know what they want until they’ve seen at least some of the options ‘in the flesh’. All of this to-ing and fro-ing is an expensive, time-consuming business.

There is an argument for using DSLs (Domain Specific Languages) to solve this problem, effectively letting the experts design part of the software themselves. However, this requires the development of a suitable language, itself a major undertaking, again requiring a great deal of input from the domain experts.

Even once a bespoke application is completed to initial specifications, it can be difficult (i.e. expensive) to change it to reflect changes in the data used by the organization, or if the client changes their mind about what they really wanted. Servers and databases may also need to be maintained, or updates/installations performed on PCs.

If the focus of an application is managing and sharing data, rather than complex automation of processes, then a wiki may well be a better alternative. With wikis, there is no up-front design required: the application grows organically as the users (the domain experts themselves) add/edit content. The users choose how things are organized, what information is important, and how it is related. Additionally, hosted wikis don’t require any installation or maintenance and users can get started right away.

Our idea with Swirrl is to add data handling capabilities into a wiki environment, so to broaden the class of problems that you can handle without needing any bespoke application development.

(Wiki globe image by J Aaron Farr)