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?'"
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!)
Personally I feel I get more recognition and appreciation when programming for a larger audience like the Internet.
Yep, sounds familiar.
:-) I could add things if I wanted to without asking anyone, and change the way that it worked, or re-write whole chunks of code if it was getting messy. As long as it did what they wanted and they had no objections I was free.
I used to work at a small local engineering company and they would say "We need a reporting program that takes the data from this Unix box and prints out nice reports in colour with plenty of options so we can select what prints." etc.
I just started to knock-up a screen with a few tabs and buttons and we would take it from there. Changing bits here and there. Adding new options when we wanted them. It was great
Now I am supporting a large mainframe system and it can take days to get approval to change 1 character of data!
This just sounds like "propietary/custom" written software rather than "situation" software, albeit combined with a certain degree of marketability predetermined during design, which is usually not the case.
It also outlines something similar to the "Google vs. Yahoo" design debate, where Google has gone with the "The user has come here to search, so lets let him search the fastest and the quickest", while Yahoo has gone with "Search is just one of our products - lets give the user a ton of options and draw him to use Yahoo! for all his needs.."
Basically, situation software just sounds like a repititious new-fangled jargon to me..
You remind me of a small job I did when working with cadastral data for the city. We needed a util to help convert some of the data in its raw form into a better laid out format in order to sell some of the data we had to the public. I said I could get most of it done within a weekend, but that wasn't quite good enough; the project was outsourced, and 2 months (and several thousand $$ later) a bloated app came back to us that only worked usably with the quicker 3/4 of our workstations and had a GUI was frankly shit.
I went and did my "weekend" hack, which ended up taking 10 days to complete. Not only was it quicker, smaller and light enough to run on every workstation, it immediately became the choice for preproduction layout. Still didn't help me get the job to do the next small app that needed doing, which was once again sent out to an external co, and in no small part due to the mr.negative supervisor who claimed I'd "cost the department thousands" by releasing my app inhouse and making the costly one redundant. Go figure
it is a perfectly decent job writing customised software for companies. pays very well and has much less stress then working for big software firms ( which you won't catch me dead doing ) i wouldn't ever take a job writing a webserver for example, i'd just advise clients to use apache and charge then do setting it up. but if someone wanted say, an appointment book system which reflected their unquie busniess requirements i'd do it in a span. it serves them exactly what they need and theres not need to wait for some development house to get off their arse to make changes if they need them.
If you mod me down, I will become more powerful than you can imagine....
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.
One of the small issues is sometimes it's bad when every little program has a new UI to learn. Not that big a deal.
Actually, there's a related issue internal to development: I find small do it from scratch implementation much better than applying some massive pre-existing gramework, ala EJBs in J2EE; when you build from the ground up, directly task-focused, and understand how to reimplement the parts of the giant framework ou need in a fairly quick way, I think you get a lot more done than trying to munge some massive beast which always seems to be doing almost, but not quite, what you want.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
As I understand it, ERP systems are a hybrid of your two approachs. Basically made-to-measure rather than bespoke or ready-to-wear: ERP systems typically are an infrastructure requiring customisation for each enterprise. Since customisation is simpler and in a higher-level language than creating a system from scratch, the cost of the ERP software plus customising developers should be cheaper. (Many made-to-measure and even bespoke tailors are offshoring the stitching today.)
Of course many small businesses can barely afford the ready-to-wear software, so they're still stuck with a bad fit. Once I can figure out exactly how to provide them with cheap made-to-measure (probably built on open source ERP), I'm going to be rich!