On Situated Software - Designing For The Few? 102
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?'"
Isnt this why MS sucks? (Score:1, Insightful)
Re:Isnt this why MS sucks? (Score:2)
I'd say (Score:1, Funny)
And never reuse the code or use the same program twice.
Re:I'd say (Score:1)
I must admit, it would be interesting if the
Re:I'd say (Score:3)
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 si
Yay - back to inhouse programming (Score:5, Insightful)
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.
Re:Yay - back to inhouse programming (Score:3, Interesting)
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
Re:Yay - back to inhouse programming (Score:2)
These days you don't need to write custom apps to do that. You just import your data into an Excel spreadsheet and hack away at it. I guess "real" programmers don't believe this is the proper way to process data, but people are doing it in the real world all the time now.
Re:Yay - back to inhouse programming (Score:1)
I myself am guilty of this as well
Re:Yay - back to inhouse programming (Score:2, Informative)
Do what the users want, show them what you do often so they can change it as it goes, and don't try to do more than they need, and, well xp recommends you try to keep it clean nonetheless so you can extend it if need be.
However this is pretty hard to apply in real life,. Lots of people who are oblivious to both usability and technical constraints come in the loop and kill it all. They require plannings and time estimation to be ab
Re:Yay - back to inhouse programming (Score:1, Interesting)
You should complain to his supervisor (Score:3, Insightful)
Re:You should complain to his supervisor (Score:1)
Around anywhere (Score:1)
Re:Yay - back to inhouse programming (Score:4, Insightful)
Also Known As... (Score:4, Funny)
Re:Also Known As... (Score:5, 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".
Re:Also Known As... (Score:1)
Re:Also Known As... (Score:2)
Re:Also Known As... (Score:2)
The guy that still has a job.
Admin scripts (Score:5, Interesting)
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.... (Score:4, Insightful)
I think the XP [extremeprogramming.org] 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.
To small for extreme, and more honest (Score:3, Insightful)
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.
Re:To small for extreme, and more honest (Score:2)
You never know how software might expand (Score:2)
No, the article is about rejecting "flexibility" (Score:2)
More recognition and appreciation (Score:3, Interesting)
Re:More recognition and appreciation (Score:1)
I dunno, as part of a huge team consisting of marketeers, graphic design folks, and server-side Java kids, I felt like a cog in the machine more than anything.
At another job, when I developed an app with a very small group of programmers to help some scientists run raw data through a pipeline and then display the results on a website only this small group ever used, I felt something like 50
Designed to scale? Where? (Score:2, Insightful)
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."
He's right, this is exactly why... (Score:2, Funny)
Re:He's right, this is exactly why... (Score:2)
New software scaling needs in distribution... (Score:2, Insightful)
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
Re:New software scaling needs in distribution... (Score:5, Insightful)
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.
Re:New software scaling needs in distribution... (Score:1)
What do you mean by "scale"? Amount of data? See Beowulf. Number of interacting components/processes? See Xfree86+GNOME+Mozilla. Number of distributed processing nodes? See Beowulf again.
Seriously, have you ever seen a real Unix shop in action? We're talking several gigabytes an hour of data flowing throug
Re:New software scaling needs in distribution... (Score:1)
2) You don't have to have common data formats. That's what filters are for -- to massage data into the form needed.
3) XML _is_ text.
4) EJB is scalable how? By running on top of an application foundation which trakes up more processor and memory than every other program on the box just to get started?
The Unix tool-based approach may not be perfect, but how "portable" do you really think EJB is? Ever tried running EJB on a micr
Re:New software scaling needs in distribution... (Score:3, Funny)
theCat
Re:New software scaling needs in distribution... (Score:2)
Which only makes sense when you are a programmer. End users aren't going to learn the gritty on the "cat" command.
When you see "user friendly" read that as "gets done what the user needs done without too much fuss". Deliver that, and you'll get paid.
I can just see it now - you're dealing with a 55 yea
I don't see it... (Score:2, Interesting)
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
Re:I don't see it... (Score:4, Insightful)
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.
Re:I don't see it... (Score:2, Insightful)
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 a
Re:I don't see it... (Score:1)
Not at all. Many free software products start out small, just for yourself (scratching an itch) or a small group of people near you. I have seen so many failed attempts at solving all problems at the same time. A few years back, lots of companies died because they spent so much time in the initial development cycle that all their money and support suddenly were gone. Many big programs today wouldn't have been wri
I think you forgot something. (Score:1, Funny)
It's 01/04, don't ruin my day, Slashdot!
Re:I think you forgot something. (Score:1)
No wonder /. doesn't work so well (Score:3, Funny)
Re:No wonder /. doesn't work so well (Score:1)
Now the question is... (Score:5, Insightful)
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.
target (Score:2, Insightful)
Re:target (Score:2)
*leans on walking stick*
When I where a lad, 'twere called "vertical markets".
</MODE>
Valid concept, but I think it's just specialisation of market with new clothes.
what slashdot editors do all year (Score:2)
Re:what slashdot editors do all year (Score:2)
Other advantages (Score:3, Informative)
One of them, CWirc [easyconnect.fr], 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
MySQL (Score:2)
all about the situation (Score:3, Interesting)
There is an intermediate level. (Score:5, Interesting)
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.
Quick and dirty vs customized vs kitchen sink (Score:2)
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 respon
Re:There is an intermediate level. (Score:1)
Everything old is new again (Score:3, Insightful)
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.
Re:Everything old is new again (Score:1)
Re:Everything old is new again (Score:2)
It was a problem right up until 23:59:59 on 12/31/1999.
A lot of man-hours and cashola were spent rewriting software and upgrading systems to avoid it. I would even be willing to argue the IT spending bubble of the late 90's, (and even the horribly accelerated acceptance of Windows NT 4.0) was not caused by cheap ubiquitous internet access, but by Y2K. Sure, internet speculation contributed, but it wouldn't have had nearly as sizable a foothold among financiers if market expectations weren't already infla
Re:Everything old is new again (Score:3, Funny)
Some things were prevented from breaking -- most of the major issues. Some things broke but were quickly corrected. And some things, as that search will show you, broke and are still broken.
Artistic Programming (Score:1)
UI and other issues (Score:3, Interesting)
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.
No social contract (Score:2)
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
Often good technique (Score:3)
Isn't that what most programmers have always done? (Score:4, Insightful)
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.
Re:Isn't that what most programmers have always do (Score:2)
ERP = Made-To-Measure (Score:3, Interesting)
Of course many small businesses
Applies to most products, actually (Score:2)
Shirky smokes crak (Score:2)
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 th
Different Assumptions are the key here (Score:2)
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 t
Easy Tools Makes it Easy (Score:2, Insightful)
Do kiosks fit in to this? (Score:2)
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.