Slashdot Mirror

← Back to Stories (view on slashdot.org)

On Situated Software - Designing For The Few?

Posted by ryuzaki0 on from the for-you-and-you-and-you dept.

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?'"

15 of 102 comments (clear)

  1. Yay - back to inhouse programming by MrRTFM · · Score: 5, Insightful

    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
    1. Re:Yay - back to inhouse programming by necronom426 · · Score: 3, Interesting

      Yep, sounds familiar.

      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 :-) 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.

      Now I am supporting a large mainframe system and it can take days to get approval to change 1 character of data!

    2. Re:Yay - back to inhouse programming by jellomizer · · Score: 3, Insightful

      But for many smaller companies you will need to put on many hats. Although you are the in-house programmer for most companies now in in this economy you will also need be able to do other jobs as well Like management, sales... and all the other stuff that a lot of techs don't like to do. If you do have a program to write you will need to spread it out over the rest of the other work you will need to do. A company of 50 employees cant usually justify to have a full time programmer paid at 45k a year. For the odd job that needs to be done (although they are often more then they think) Plus for these situations there will be long times that you are not programming because you made all the apps that the group needs to run for a while.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
  2. Also Known As... by femto · · Score: 3, Funny

    The Quick Hack.

    1. Re:Also Known As... by mystran · · Score: 4, Insightful
      Not funny, but insightful!

      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.
  3. Admin scripts by SavingPrivateNawak · · Score: 4, Interesting

    Everybody doing a little admin on his linux box does exactly this...

    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-t hings,
    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!)

  4. The key.... by D-Cypell · · Score: 3, Insightful

    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.

  5. More recognition and appreciation by jsinnema · · Score: 3, Interesting

    Personally I feel I get more recognition and appreciation when programming for a larger audience like the Internet.

  6. Re:New software scaling needs in distribution... by Anonymous Coward · · Score: 5, Insightful

    One of the major points of Unix design is that small programs are more usefull then big ones. Ones that incorporate a menu-driven user interface are less usable then ones that can receive input and output.

    Every program is a filter.

    Information in, modify it, and information out.

    That's it, that's all that programs do. So menu driven software only takes information from one source (the user) while input/output style programs can take information from many places.

    So when designing a program you need to figure out what it does, find out how to get it done and finished in the simpliest way possible, and then make sure that it isn't going to f*ck that up. Anything extra is a liability.

    Small programs are much longer lasting. You code one piece of software, why is it a good idea to code the same functionality over and over again? What? Wasn't the first 30 times you wrote a function good enough?

    Take the "cat" command for example.

    When will that never be usefull? It was used years ago and will be used years from now. You can take the code and incorporate it into other programs, but the functionality and the nature of the programs will awlays be there.

    You want to dump the output of a text file anywere, into anything? Cat can do it. It can copy files, can be used to provide information to other programs, it can take any information from anywere and move it anywere else.

    You know a easy way to ruin "cat"?

    Make it go: "Are you sure you want to cat this file? Y/N"

    Instantly useless.

    Weird stuff, userfriendly 9 times out of 10 equals user useless.

  7. No wonder /. doesn't work so well by whimdot · · Score: 3, Funny

    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.

  8. Re:I don't see it... by Anonymous Coward · · Score: 4, Insightful

    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.

  9. Now the question is... by Wiktor+Kochanowski · · Score: 5, Insightful

    ... 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.

  10. Other advantages by f8ejf · · Score: 3, Informative
    I own/maintain several very specialized programs.
    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

  11. There is an intermediate level. by AlecC · · Score: 4, Interesting

    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.
  12. Isn't that what most programmers have always done? by mwood · · Score: 3, Insightful

    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.