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.
Everyone must write a new program every time he wants to do anything.
And never reuse the code or use the same program twice.
Sig. No Sig.
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.
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.
...small project teams in big companies end up developing sophisticated Excel Spreadsheets.
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..
Er guys? Did you know which day it is? I mean, what's up with all those interesting and important news?!
It's 01/04, don't ruin my day, Slashdot!
All Hail Discordia. Hail Eris. Fnord.
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.
Because for anything more complex than 100 lines of code, you are quite likely to have bugs.
So why replicating those bugs, when you can use existing, stable code?
Of course, I'm not talking about web sites or small VB/perl/shell appliances for converting, say, a bunch of photos into a nice custom album.
... 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.
I just found out what slashdot editors do all year: they prepare for this day, year after year, to make April 1st the great holiday we geeks deserve! Thanks! Oh, and if you ever need a job, Google is hiring...
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
I'm still trying to figure out what that cheap MySQL plug was in the middle...
Whee signature.
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....
Someone who uses the phrase "persistent cognitive dissonance" must be taken with a pinch of salt.
I wonder if the software code he/she produces is as shit as the writing - and I'm not trolling.
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
Ya know this article is right. We shouldn't program for the masses, just individuals. We should be able to put up colored modules and let people 'Draw' thier own personal applications.
You say things that offend me and I can deal with it. Can you?
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
There are many, many tasks out there that are "orphans" in the software world. Much like Orphan Drugs, there is not enough of a demand for large organizations to support them. So personally writing code to support a specific function is the only way to get it done. Why require that a developer with a specific need modify his design to support tasks that he does not need? Why not, rather, expect the larger projects to support his problem? Because they will not!
I have had several apps on the web available free for download for years. It is a lucky happenstance that the specific problem I was solving is the same that other programmers have. Thus there is a little bit of code on the Net to help whoever needs it. But I would not have written that code at all, were it not for my own task.
I think that there is a "gimme" attitude on the Net, where people expect software to be provided for them for free. And sometimes they resent that their wants are not always fulfilled. I have heard, several times, the argument: "If your software does not give me [YOUR FEATURE HERE] then I refuse to use it." Oh dear, I am so shattered.
There is a need for all types of projects, big and small, wide or narrow.
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!
The idea of having a lot of little tools (Report A tool, Report B tool) seems attractive, but then one has the support burden of modifying all of those little tools. It seems easier to either 1) consolidate them into a general purpose report tool (the typical Swiss Army knife app) or 2) bundle the supporting modules into a library and passing off the responsibility of what kind of report tool to generate to another group of developers (the Perl approach).
The idea of developing (and maintaining) a large number of special purpose programs without migrating in direction 1) or direction 2) is well-intentioned, but it doesn't seem to last.
The idea being that if you know your audience, and they all know one-another, then rather than anticipating every contingency, you can create someting precision-tailored to the specific task.
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.
Forgot to say that the work is always new, so it's more fun too!
Many in the environmental community have made this argument as a general principle: products should be designed with a local focus. For a fabulous example, think about soap/detergent. Given how much the content of available water changes around the world -- different minerals in different proportions -- wouldn't it make sense to have cleaning products that are specifically made to work best for your situation? Instead, everyone washes their clothes with Tide, and most of us have to use more of it than should be necessary because it isn't very effective in our water. This leads to a higher chemical content in the waste water, which flows back out into our environment. Ta da... pollution!
I don't have enough fingers or toes to count the number of "small apps" that some wonk wrote to make life easier for a few folk (maybe an excel spreadsheet + macros) that ended up living long after their creator left the company. The people who use the app have no clue how to do the job manually, just how to run the macro ("Simply open whtzits.xls and click the "RUN" button"). Then something breaks or they need new functionality and it is YOUR job to wade though that crappy code rewrite it in a more suitable language/platform.
Oh, and there are several Fortune 100 companies who have their core business running on, or key business decisions based upon this crappy "software."
Yeah, right.
What the author keeps describing, but does not specifically articulate is that the 'situational software' is more implementable and works better because it uses a different set of assumptions in the design.
This set of assumptions is based around what features can be eliminated because of the small group. E.g., they could eliminate a reputation system (a la eBay) because they assume that the set of users already know everyone's reputation.
What is the best code? Code that is never written -- it takes no time to write, runs in zero time and has no bugs! The successful 'situational software' is simply taking advantage of this.
Even with the features that do need to be implemented, it is always easier to solve the specific problem than the general problem. solving general problems well requires very careful thought in the UI and internal design to handle a variety of uses or cases that will be encountered in a scaled app. Just take a set fo fields to enter an address. If you assume only US addresses, it is trivial, but if you want to scale globally, or, heck, just add Canada and Mexico, it suddenly becomes more complex to present and run well.
These sort of situation-specific programs are not new. I'm sure there's hundreds++ of little apps built to track someone's mom's recipies, built with only the measuring system (Us/metric) and searching types that Mom uses, not for general use.
So, it is a good descriptive article as far as it goes, but I think the real issue is how to build toolkits so that the app can be scaleable, but also be efficiently and effectively 'situationalized' for its various sub-audiences, like the apps he describes, not like the "Hello Dave" on the ATM that he properly derides.
Now the easy pickings have been taken with generalized software leaving only the less lucrative task of meeting the rest of customers needs more completely with more specialized software.
I missed that the first time. I guess that's true of any government job - damn the expenses and everyone gets to stay forever!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
But if you want a really nice car, exactly the way you want it, then you DO have some company like Lamborghini or one of those people on "Rides" or "American Hot Rod" build it from the sheet metal up.
You buy a mass-produced car because you either can't afford or can't justify the expense of a custom one, but you have to admit that all things being equal, you'd pick a Lamborghini (for example) over the Civic you drive now.
Who determines when N-squared is too large? Management has a tendency to maximize profit and therefore to let N get large. If you let software go in the wild under these conditions it's only a matter of time before a manager asks his techie why the software that worked yesterday doesn't work today, or why it's going to take a month out of his quarter for re-design if we want to change the forum or layout of the group.
Writing form-fitting software is not an asymptotic approach to design and breeds laziness in all levels of design in a design group. Change is the nature of the market and software written for that market must be able to handle that change.
Cheaper and faster doesn't teach the programmer anything; in fact this dulling effect can bore a programmer out of his job. Just because you ignore scalability doesn't mean the software has fewer scalability issues. You'll find the simplest changes much more challenging than they should be. If users aren't willing to learn software (or any other skill) to do their job better, this also breeds mediocrity.
How rare is it to find programming talent that can't write utilitarian software? Software programmers are born lazy. This is the nature of all inexperienced and un-trained programmers. With experience in a field, skills become secondary to philosophy. When you focus purely on skill and ignore philosophy you become doomed to peak at mediocrity; thus the world before XML and other important abstractions.
I thank God that mathematicians are free to think asymptotically. If their creativity were confined to industry they would be pressured to stick with 4 function calculators and work everything else out on the fly.
I would suggest that a program like "Teachers on the Run" contain the ability to setup a basic schema via an INI file so the schema can be changed based on the needs of the user very quickly and easily.
The trade-off in popularity came when your programmers got geeked about their product - which is very healthy. But the fact that we live in different locations of the country and we both have heard of ratemyprofessor.com proves that when Web School app developers get excited, indeed the oceans and the continents start to heat up.
The pier pressure on deadbeats approach works only in the vacuum of an academic setting.
"We rarely rely on the cognitive capabilities of groups, however, though we rely on those capabilities in the real world all the time." A large part of industry is trained to perform daily functions - novelty only occurs when a new system is implemented, and contrary to popular belief many people don't use icons because they're drawn toward the usefulness of the pictures, but out of trained procedure and rote documentation. When we use schemas that developers can easily modify, we allow the trained and very bored masses that ability of having a deeper understanding of the system, which improves their ability to submit change requests, not to mention the improved ability to train new employees.
The two mid-term critiques might have been a reflection of people finally learning a centralized abstraction such as the Web. Remember the web is still new to most people even though it's been around for 10 years. As it permeates our culture you'll be more and more blown away at how well users integrate higher technology into their lives. I'm amazed every day when I hear non-technical types talking about upload sizes, bandwidth limitations, proxy servers (etc.) like they were talking about an episode of Oprah.
Do you think it would be harder for most kids born in the 80's to use a web form or a beta-max interface? Most kids born in the 80's have never heard of beta-max, and apart from novelty might quickly ask those important questions.
Deploying services on an Intranet would solve your physical layer issue with web deployment.
"everyone knew and trusted Scott" - again, this only works in the vacuum of an academic setting.
In the information age, where the ent
Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose.
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
Indeed. And the other thing to be wary of is that software can often expand in many different directions, and it takes quite a bit of experience and intuition to tell which ones are likely enough and/or easy enough to allow for. Often it's a good idea to solve the much more general case or allow for particular types of future expansion, but sometimes it's just not worth the extra work.
Ceterum censeo subscriptionem esse delendam.
Kiosks have always slightly mystified me, and it seems that what Shirky is describing is relevant to their design, although because his angle is that he has discovered a new phenomenon, he doesn't mention them.
Airports, stations, public buildings... trackerball, touchscreen, crash, crash, crash. Ever since about 1993. They're still around though, and being consistently ignored by all who walk past them.
"And the meaning of words; when they cease to function; when will it start worrying you?"
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!
Rule of 150 applies: too many of any group, and the social fabric breaks down.