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
Everybody doing a little admin on his linux box does exactly this...
t hings,
My scripts are very specialised and wouldn't be as useful to somebody else but they serve my purpose very well.
Their limited scale is an advantage since I don't have to respect interface compatibility between versions, etc.
This really eases the "upgrade" process when you think of a new super functionality-that-unfortunately-breaks-a-lot-of-
It's my sole responsability and I am not blocked by others that would have different uses of the scripts and would not care about the functionality (but would care about the incompatibility!)
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.
This is done all time time, people hack some throwaway code to do a simple task, which then grows for some time, until it reaches the state where it satisfies the 1 to 5 users it has, but can't really be transferred to another system/environment without so much hassle that nobody bothers to.
Some of these hacks later become "real software", while most stay like they are. I'd claim that this is awfully more common practice in the Unix world, thanks to tools like bash/perl/python and the ultimate-unix-scripting-language C. But really, most software written in the world is VERY likely to belong into class "a quick hack".
Software should be free as in speech, but if we also get some free beer, all the better.
Basically, situation software just sounds like a repititious new-fangled jargon to me..
I agree.
The point to successfull software design is:
1. Find out what the user wants to be done.
2. Do it
3. Don't screw it up
Bad software design goes like this:
1. Figure out something to do.
2. Make it look cool and make it fast, or at least increadably feature rich.
3. Try to convince people to use it.
4. Make it look flashy, and with that flash hide the functionality so that people depend on it without understanding it.
5. have lots of options.
6. make it so people can use it without thinking.
(6 months later)
7. Fix the horrible mess we just made.
... 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.
An interesting article, but on the other hand you can look at it the other way. Larry Wall developed perl because he was fed up with writing special pupose report analysers, and built a general purpose report-analyser-generator - which turned out to be mind-bogglingly useful for other things. But it is a good idea to avoid feature creep: there is always a tendency, if not resisted, to add global features to a quickie "just in case".
But the article was talking about a geograpically close-knit community. I write software fore spcialist machines used by a technically close-knit community. As such, my user interfaces can take advantage of their knoledge (for example, you can assume that a video editor can do timecode arithmetic). The trouble is the marketing droids don't have these skills, and try to force the UI to have features to make it iasy for them to use, rather than the end user. So they want every timecode box laden with calculating abilities, and boxes to show differences between timecodes etc. Lots of screen area, lots of niftiness - "look, I enter it here and it changes over there", but not much use. Luckily, my corporate culture allows me to fight back - "It's not for you, dummy, it's for " carries some weight. The problem sometimes comes with the customaer management, who pay the bill but are not themselves users. All you can ope is the users can control their management like I (sometimes) can mine.
Consciousness is an illusion caused by an excess of self consciousness.