automated commit from wiki

clay shirky on situated software.md

@@ -0,0 +1,25 @@
+[link](https://web.archive.org/web/20040411202042/http://www.shirky.com/writings/situated_software.html), via [robin sloan](https://www.robinsloan.com/notes/home-cooked-app/) 
+
+>  We've been killing conversations about software with "That won't scale" for so long we've forgotten that [scaling](#scaling) problems aren't inherently fatal. The [N-squared problem](#computational complexity) is only a problem if N is large, and in social situations, N is usually not large. A reading group works better with 5 members than 15; a seminar works better with 15 than 25, much less 50, and so on.
+
+> This in turn gives software form-fit to a particular group a number of desirable characteristics -- it's cheaper and faster to build, has fewer issues of scalability, and likelier uptake by its target users. It also has several obvious downsides, including less likelihood of use outside its original environment, greater brittleness if it is later called on to handle larger groups, and a potentially shorter lifespan. 
+
+... 
+
+>  There is another strategy, however, analogous to asking the user to recognizing icons; the designer can simply assume the group has a certain capability, without needing to recapitulate it in code. If you have an uncollected payment in a communal buying pool, the software can kick out a message that says "Deadbeat alert. Deal with it." A real world group will have some way of handling the problem, usually through moral suasion or the threat of lost reputational capital, or even, in extreme cases, ostracism. 
+
+...
+
+> You need to scale because building a useful web application is so expensive, but much of the expense comes from the requirements of scale. Furthermore, these scarcities [amplify](#positive feedback) one another: You need a big hardware budget to build an application that can scale, but you need good programmers and system administrators to handle the load, whose salaries require an increased marketing budget, to attract enough users to pay for it all. 
+
+...
+
+> Seen in this light, the obsession with [personalization](#personalization) of Web School software is an apology for the obvious truth -- most web applications are impersonal by design, as they are built for a generic user. Allowing the user to customize the [interface](#user interface) of a Web site might make it more useful, but it doesn't make it any more personal than the ATM putting your name on the screen while it spits out your money.
+
+> Situated software, by contrast, doesn't need to be personalized -- it is personal from its inception. 
+
+...
+
+>  Expectations of longevity, though, are the temporal version of scale -- we assume applications should work for long periods in part because it costs so much to create them. Once it's cheap and easy to throw together an application, though, that rationale weakens. Businesses routinely ask teams of well-paid people to put hundreds of hours of work creating a single PowerPoint deck that will be looked at in a single meeting. The idea that software should be built for many users, or last for many years, are cultural assumptions not required by the software itself.
+
+> Indeed, as a matter of effect, 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?"