WorkingSoftwareIsTheGoal. Don't forget this. Email archives, detailed specs, project plans, minutes of meetings. All of these HELP towards the goal, but they are rarely the goal themselves.

Non-technical management can have a tendency to forget this - software is something they don't understand. It's a magical intangible, that seems (to them) to require indeterminate amounts of time and effort to make and can't be quantified or qualified. There's an element of surprise when nine-foot-thick piles of paperwork STILL fail to make the customer happy.

-- KatieLucas

Helping someone do his job better is the goal. There is a lot of "working" software that doesn't help meet that goal. See LevelsOfSoftwareSuccess.

BoostingEndUserProductivityIsTheGoal -- PhlIp

----

This is true - but this is why the customer should get to define "working". For both people. You're right in that there's a lot of non-crashing software which doesn't help because it's the wrong software. There's also a lot where the "customer" is happy and pays for it, and therefore the supplier gets to count it as a success, but the actual users aren't happy. But then you could say that's not your fault, it's the fault of the broken systems in the customer company...

I'm more worried about a lot of the "we filled in the forms, ticked all the boxes, the project was a SUCCESS, but the customer sued us/didn't pay us and we don't understand why..." attitude, because that's not just a failure, that's a failure to learn.

-- KatieLucas


It's more fundamental than that. The goal of all software systems is to produce something that reduces costs, mitigates risk or increases income in a business or organization. Even software to produce research results ultimately has one of those three aims.

-- NeilWilson

I'm not so sure, unless you think the purpose of all research organizations is to increase their income. A software tool to help an academic research organization sequence a genome doesn't really fit (you could just about squash it into "reduce costs", but that's not really the goal.

And it often needs to continue to do these over time. So it's not enough to get the software working for one release, you need to set things up so you can continue to do that as the world changes. This means documentation etc can be a vital part of the goal.

''I still suggest that the purpose of software is to help someone do his job better. Reducing cost, mitigating risk, or increased income are desired by products of this, but are rarely verifiable. I have never seen a cost benefit analysis of a word processing program (plus the machine it runs on), yet I see them on every desktop in the office.''

Gartner will certainly sell you such a cost benefit analysis. I'm sure most companies don't look at such things, though.

How do you explain to somebody who has been downsized by a computer system that in actual fact it is helping them to do their job better? -- NeilWilson

[It helps the remaining people do their job better, or they couldn't have downsized.]

''Never blame a management decision on a computer program.''

Well, it's not really at the individual level. It's (supposedly) making the organization more effective/efficient.

A good point, but in that case why are companies so tolerant of it (apparently) clearly not doing? Why DO they pick Lotus Notes (when every user I ever come across hates it and finds it troublesome) instead of Wikis and regular email? Is it just that management don't know how to measure that effectiveness or efficiency? -- KatieLucas

''Why do the users continue to use Lotus Notes? Probably because using it provides them with more benefits than not using it. Saying something is difficult to use is not the same as saying it is not useful.''

Yes, I think there's confusion between awkward and effective here. As someone who has been responsible for Notes in a past life, and a wiki in the current one, I'd love to have Notes in the current organization. Much more poweful organization of pages, better structuring of data, digital signatures, authentication, off-line use (reading and editing), multiple servers, quick development and distribution of applications. Yes, it's slow and clunky, but the idea that companies should always replace it with wiki&email is pretty silly.