Aye. Joel attributes sees the impulse to rewrite as a result of programmers' laziness about supporting existing systems. But I think many programmers who were present at the original creation of software recall the compromises and mistakes that came as a result of deadline pressure. Many suits say "we have to make deadline; we can clean that stuff up later." We all know that organizations rarely have the discipline to actually do that, and Joel makes it clear that it's not such a good thing even when they do.
OSS development works best for systems decomposable into modular components, where the population of people who use it overlaps with the population of people who code and improve it. Consequently, OSS systems appeal to a programmer's temperment: they require that their users learn a lot about how they work, but in return they offer generalized tools of great power and flexibility.
Most people have a very different temperment. They like specialized tools that do a specific job well. They will accept limitations in return for something that they can use and learn easily. There is a lot of talk in the OSS community about how regular people must eventually accept the need to learn about how computers work, but this is in fact unnecessary, undesirable... and impossible.
The focused, specialized systems that appeal most to regular people have coherent designs that one cannot simply decompose, modularize, and incrementally improve in little bits. They are cathedrals, in ESR's metaphor. The methods of OSS will never work to solve those problems.
As a professional interaction designer, I am enthusiastic about using underlying architectures based on OSS, but I do not believe that OSS methods will ever produce good interaction design for regular people.
From my partisan position as an interaction designer, I have to say that the creation of a seperate interaction design team is the best thing that you can do to solve these kinds of design problems. The interaction design team should contain only a handful of people (no more than four, and preferably less), should do its work before coding begins, and should have a mandate to create a behavioural spec.
That should help resolve the problems raised above:
1. The interaction design team can really focus on users' needs and perceptions. 2. Good interaction designers know that users ask for features when they are in pain, but that users don't need the candy they asked for -- they need a nourishing meal. 3. Amen. The design team needs to look at the end users, not the purchasers of the system. 4. The design team's behavioural spec gives you something to sign off on, to control the project. 5. Too many projects have arbitrary schedules because managers have such blunt tools for trying to keep control over the project. After you have a spec, then it's possible to create a realistic schedule. 6. Again, the spec is a good guide to how you can break things up into chewable pieces. 7. Again, the spec is the earth that you keep in the window!
Technically-oriented people like flexible tools that reward a deep understanding of how they work, but normal people actually prefer inflexible tools that enable them to do a handful of key things simply and effectively. (Consider manual transmission, Web browsers, or VCRs.)
Trying to be all things to all people is a hopeless task. I can imagine a few different shells, targeted at different people to address their needs.
Slashdot Mirror
Aye. Joel attributes sees the impulse to rewrite as a result of programmers' laziness about supporting existing systems. But I think many programmers who were present at the original creation of software recall the compromises and mistakes that came as a result of deadline pressure. Many suits say "we have to make deadline; we can clean that stuff up later." We all know that organizations rarely have the discipline to actually do that, and Joel makes it clear that it's not such a good thing even when they do.
OSS development works best for systems decomposable into modular components, where the population of people who use it overlaps with the population of people who code and improve it. Consequently, OSS systems appeal to a programmer's temperment: they require that their users learn a lot about how they work, but in return they offer generalized tools of great power and flexibility.
... and impossible.
Most people have a very different temperment. They like specialized tools that do a specific job well. They will accept limitations in return for something that they can use and learn easily. There is a lot of talk in the OSS community about how regular people must eventually accept the need to learn about how computers work, but this is in fact unnecessary, undesirable
The focused, specialized systems that appeal most to regular people have coherent designs that one cannot simply decompose, modularize, and incrementally improve in little bits. They are cathedrals, in ESR's metaphor. The methods of OSS will never work to solve those problems.
As a professional interaction designer, I am enthusiastic about using underlying architectures based on OSS, but I do not believe that OSS methods will ever produce good interaction design for regular people.
From my partisan position as an interaction designer, I have to say that the creation of a seperate interaction design team is the best thing that you can do to solve these kinds of design problems. The interaction design team should contain only a handful of people (no more than four, and preferably less), should do its work before coding begins, and should have a mandate to create a behavioural spec.
That should help resolve the problems raised above:
1. The interaction design team can really focus on users' needs and perceptions.
2. Good interaction designers know that users ask for features when they are in pain, but that users don't need the candy they asked for -- they need a nourishing meal.
3. Amen. The design team needs to look at the end users, not the purchasers of the system.
4. The design team's behavioural spec gives you something to sign off on, to control the project.
5. Too many projects have arbitrary schedules because managers have such blunt tools for trying to keep control over the project. After you have a spec, then it's possible to create a realistic schedule.
6. Again, the spec is a good guide to how you can break things up into chewable pieces.
7. Again, the spec is the earth that you keep in the window!
I would argue that the real problem is that systems like NT and Linux are designed such that so many routine uses require your face.
Why should it require our best gurus just to keep the email flowing? Is that not a waste of talent?
Technically-oriented people like flexible tools that reward a deep understanding of how they work, but normal people actually prefer inflexible tools that enable them to do a handful of key things simply and effectively. (Consider manual transmission, Web browsers, or VCRs.)
Trying to be all things to all people is a hopeless task. I can imagine a few different shells, targeted at different people to address their needs.