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?'"
The only reason software "designed for large numbers of users" fails more often than that designed for few is because there is a much larger userbase to nitpick and 'test' it.
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
The key to efficient software design is flexibility. Designing for the current problem while allowing the easy migration to more complicated issues (such has massive scaling up).
I think the XP guys outline this particulally well.
Design for today, allow for tomorrow. Too much software is designed with only one of points in mind. The great software covers both.
Not from what I've seen (or maybe it's taught but not followed?)
Many of the code and sites I've seen have scalability problems, and those aren't the ones that explicitly say "not designed to scale."
Everybody's a libertarian 'till their neighbour's becomes a crack house.
I think what the article is talking about is an edge of what is going on all over, things like RSS feeds or other things that become small pieces of a very custom application for many users.
In a way it's sort of the "UNIX way" of thinking, having a lot of small tools and linking them together to complete a task - only at a higher level and with richer building blocks.
I think the challenge for anyone building and selling software that wants to ride this new wave is then to say - how can we create software small enough to be useful part in this world, but not not harden it so much that it becomes too impersonal or inflexible to communities?
It's a sort of scaling in distribution, not performance, problem. You need to figure out ways to let the user pick up a piece quickly to create something for his mom or a group of friends. The example of RateMyProfessor.com says something... why didn't the group pick up on that? It does seem that just some interface being slapped together by somebody a few people knew had a much larger impact and willingness to adopt - and things like that happen all the time in business too, with spreadsheets or project templates that people pass around because someone respected made them, even if there might be slightly more impressive ones available from outside sources.
So what could RateMyProfessor.com have done to succeed? I'm not sure they could have. They would have had to build some kind of API to a rating engine - but then that kind of piece is too specific, and not as flexible as a simple DB. I don't know if between HTML and PERL and MySQL there was really ever any room for them. That is also an important lesson for people building things that look like services to the masses - will the masses be able to serve themselves almost as easily? Are you really providing a piece of the puzzle, or just a box for the puzzle, and do people want a box?
I don't know if such things will ever displace large software though, in the same way that there still were programs like Emacs and Framemaker on UNIX long ago even though you had all these cool small editing tools like cat and sed (and ed which someone else will provide a link and diatribe about).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I think the kind of stuff ebing talked about here is things that are too small for any process at all - no matter how extreme. And they are programs with no pretension for any kind of future scalability, becasuse they will never need it.
The contrasts with a number of XP results I've personally seen where the result was , as you say, supposed to migrate up to better scalability - but because that wasn't thought about in design to start with, the end result was a mess.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Seriously - the second time around, have your version ready - when it becomes widely deployed and used again go to this guys supervisor and ask for his job pointing out how much HE is costing the company. It sounds like his position is completely useless anyhow so the company could get rid of a headcount. It's guys like that that suck the life out of a company.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
I think there is nothing to justify that new name - 'Situated Software' seems to be just software with a narrow target. The whole rant with all examples is just stating the obvious truths about targetting. Perhaps there is an argument that when programming is easier (with better hardware, languages and libraries) then it economic to target it on narrow groups, but that whole story is a bit overblown.
Didn't we try this already? I mean, wasn't the Y2K problem largely caused by this kind of thinking along with compelling limitations on hardware? You know, "Let's just design it for the hardware we have and when cheaper for powerful hardware comes around, we'll rewrite it." At least that's what TV says.
"Lawyers are for sucks."
- Doug McKenzie
I think Shirky's point is more than that good design is important, but that design for small groups is inherently better -- and I think it's wrong because of that. The main benefit of targetting small groups is that it makes step 0, which you didn't list but is the MOST important step, much harder to screw up:
0. Identify who, and what situations, you're designing for
If you don't do that, you'll design crap that doesn't do anything well for anybody. If you identify your user and what they're doing, you at least have a shot at making your software handle that situation magnificently. And if you choose your user/situation right, your core users will be ecstatic and the users who need to accomodate software tailored to someone else will be the users who are most up to the job.
Most of these ideas bear an uncanny similarity to those in "The inmates are running the asylum" which is also a pretty amusing read.
What's a sig?
Think of all the guys'n'gals slaving away at payroll programs designed for one company. Not exactly a wide audience, but OTOH the one company gets an exact fit to its needs.
Thing is, most payroll programs are pretty much alike, so there's opportunity for some vendor to offer a somewhat poorer fit for much less money than custom-tailored software. Some customers will be happy enough with off-the-rack software, but some will have needs or desires that still prompt them to pay the price for a one-off system.
I believe there'll always be a market for custom-tailored systems, but it will shrink. The off-the-rack software jobs are the ones going overseas, just as was done in the garment industry. It's still hard to do tailoring over the phone, so those who need it will still patronize local talent.
Moral of the story? If you want a long career making good money in software, one way is to seek out the work that has no mass market, and the single-use projects. It's hard work, but that's what makes it worth more.
Writing your own home-grown app is a function of how hard and how expensive it is to do. With pretty simply WYSWYG tools like Dreamweaver that has good support for making data-driven apps, anyone willing to take a week to learn can do it. But if research projects underway on allowing "programming for dummies" tools hits the mainstream -- Clay's observations will really come true. If you can use a combination of natural language, and drawing information diagrams with icons, then literally anyone can write applications. They won't be pretty - but they'll probably be good enough for home-grown 10 user applications. TechPolicy
TripInvite.com: Group Travel Made Simple Evit