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
The Quick Hack.
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!)
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.
Personally I feel I get more recognition and appreciation when programming for a larger audience like the Internet.
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
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..
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
Too many users and the social fabric has broken down. The application has attempted to scale and it copes, in so much as the servers staying up is a measure of success. But look at the contents these days.
... 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.
One of them, CWirc, has a known target of maybe 15 people, and another 50 occasional users. And everybody who uses the program seems to like it a lot, because:
It caters to their specific, specialized desire
I have time to implement or improve things by request, to fit someone's wish almost to a tee (meaning, I don't have to make compromises)
The project is so low-bandwidth and simple that I can make it evolve exactly like I, and the few users, want, at the pace I want
So, while big projects with wide audiences are good, small (and also very small) ones with a very small audience have their place too. That's what makes open-source / free software work, because Microsoft and the likes don't have time or money for smaller projects, and big generic ones often don't do what people want.
73 de F8EJF
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.
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
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
I don't agree.
I dont' believe that situatued software is contrary to the idea of code reuse.
The only thing I beleve this approach is contrarian to is to the idea of "mass-use" software being developed to appeal to the lowest common denominator. Rather than ending up as trying to be something to everyone, the ideology here is more inclinded towards trying to be everything to someone (more or less).
If you want to reuse code to attain the objective, it's surely fine. I mean it's in no way mandated that situational design should always be from the ground up. That would be outright silly.
This can be scaled up to Enterprise levels as well. The code moves away from the "quick hack" standpoint, but the goals can stay the same. Rather than trying to write an uber-app, you have a very solid, very consistent shared data layer (either a database or a set of business objects), and then tons of user specific (or role specific) applets feeding from it. That lets you have your core architecture team modeling your business reality, and your user-facing teams out talking to the users, building use cases, and writing software to solve specific problems. Cuts down on the size of the apps, and also reduces training costs as each user or group of users have exactly the software they need to do their job - no less, and specifically no more.
You're special forces then? That's great! I just love your olympics!
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
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!