March 2004 archives from

Piotr's R&D blog

Clay Shirky has published an essay on situated software (edit: linked on Slashdot), that is software designed and implemented within a specific (social) context. The crux of his point is that when writing software for a small audience we can afford to ignore many of the ironclad rules of enterprise-level software design: not all software needs to scale, or implement strict security restrictions. By ignoring situated software in our software engineering classrooms, we are perpetuating the myth that all software must be "big" and leaving our students ill-prepared to take advantage of smaller but potentially more rewarding opportunities.

A recent case example from my own portfolio is MayaStar, a distributed rendering coordinator that I wrote and deployed in the last few weeks. Normally, in software of this type, you need first and foremost to consider scalability, robustness and security. The application must be able to deal with hundreds of (usually dedicated) render boxes, failover gracefully and deal with users competing for compute time. These are all important considerations, yet catering to them sacrifices usability and administrability. I thus ultimately rejected the possibility of using an existing app (e.g. Smedge2, Render Max, Muster, Spider, etc.) since they all required that the machines share a filesystem (can you say "VPN"?) and posting a job was an overly complex endeavour, especially for an artist.

For MayaStar, I made the assumption that the application would be used by at most a small studio (5-10 people), working exclusively in Maya, with access to maybe a couple dozen potentially widespread machines and little IT support. Scalability was thus not an issue: as Clay says, O(n²) doesn't matter if n stays small. While the software is somewhat robust, I assumed that the users wouldn't be above rebooting a misbehaving machine when necessary. There is no need to set up a VPN (a plain Internet connection will do), and posting a job requires only one numeric parameter. Most importantly, all users can examine, move and delete all jobs. The application relies on the social context (a small studio or classroom) to deconflict prioritization and provide access security, eliminating the need for authentication and simplifying the user interface.

Although these characteristics necessarily limit MayaStar's applicability, they (should) make it much more adoptable in its intended setting. Speaking of which, I wonder how situated software relates to adoption-centric software engineering? They seem to be attacking the same issue from different sides: situated software make simplifying assumptions based on the intended adoption community, while ACSE tailors software features to increase adoption. Situated software is more adoptable; perhaps ACSE should more formally investigate situated software as a possible design strategy?