Slashdot Mirror
On Situated Software - Designing For The Few?
janbjurstrom writes "Clay Shirky has published a thought-provoking (and long) essay discussing the concept of 'situated software', musing on changes in software development, from general systems catering to thousands towards applications 'form-fitted' to small, specific groups and particular social contexts. A lot of interesting observations about the differences." Shirky argues: "Most software built for large numbers of users or designed to last indefinitely fails at both goals anyway. Situated software is a way of saying 'Most software gets only a few users for a short period; why not take advantage of designing with that in mind?'"
I worked as an in house programmer serving 10 or so people (data manipulation, etc) and it was great.
No specs, meetings, or other bullshit - they would say 'I want something that does so and so' and after a few screen prototypes, I'd go off and build it.
*sigh* - these days it takes 2 weeks for a team of 4 to decide what database version to use.
You can't expect to wield supreme executive power, just because some watery tart threw a sword at you
One of the major points of Unix design is that small programs are more usefull then big ones. Ones that incorporate a menu-driven user interface are less usable then ones that can receive input and output.
Every program is a filter.
Information in, modify it, and information out.
That's it, that's all that programs do. So menu driven software only takes information from one source (the user) while input/output style programs can take information from many places.
So when designing a program you need to figure out what it does, find out how to get it done and finished in the simpliest way possible, and then make sure that it isn't going to f*ck that up. Anything extra is a liability.
Small programs are much longer lasting. You code one piece of software, why is it a good idea to code the same functionality over and over again? What? Wasn't the first 30 times you wrote a function good enough?
Take the "cat" command for example.
When will that never be usefull? It was used years ago and will be used years from now. You can take the code and incorporate it into other programs, but the functionality and the nature of the programs will awlays be there.
You want to dump the output of a text file anywere, into anything? Cat can do it. It can copy files, can be used to provide information to other programs, it can take any information from anywere and move it anywere else.
You know a easy way to ruin "cat"?
Make it go: "Are you sure you want to cat this file? Y/N"
Instantly useless.
Weird stuff, userfriendly 9 times out of 10 equals user useless.
... how to capitalize on that trend?
How to market yourself as a developer (preferably independent) so that you can make a nice living doing this kind of localized software?
This is what's on my mind as I contemplate starting my own software company. I noticed the same thing as the author: there's a lot of demand for "small" software which is not being met, or is being met by second- and third tier programming talent, and the quality of results is quite often offensive.