2004-10-7
Where do you want to go today? A three hour tour, a three hour tour
Yes, I came up with this title. It's time for another lesson on how things used to be better, and how we have screwed it all up. But not really. Unix is still alive, and you can still do things the Unix way. Anyway, this isn't a rant or one of my usual tomes, I will keep this one terse. These are the rules of the UNIX philosophy, with application to how the industry, aka Microsoft, measures up.
1.Rule of Modularity: Write simple parts connected by clean interfaces. Hah! Microsoft says they write simple big software. It's not simple, it's big, and it's not clean.
2.Rule of Clarity: Clarity is better than cleverness. Unfortunately I see neither in modern software.
3.Rule of Composition: Design programs to be connected to other programs. Well, sometimes their programs connect to other programs. In the most unnatural obfuscated way possible. Let's make the software connections as brittle as possible, and provide no way around when it breaks.
4.Rule of Separation: Separate policy from mechanism; separate interfaces from engines. Do we let the mechanism dictate policy? Often. Do we let engines define the interface? The real problem seems to be creating engine work just so we can have even more features in the interface. And creating more mechanisms to mold to our policy.
5.Rule of Simplicity: Design for simplicity; add complexity only where you must. When was the last time something was simple?
6.Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do. As opposed to writing a big program so ours can be bigger than theirs.
7.Rule of Transparency: Design for visibility to make inspection and debugging easier. Well, old binary only, propietary design Microsoft is at the other end of the spectrum. Put 2" thick titanium plating over the windows, and weld shut all ventilation shafts. They've done an amazing job at making the software world the least transparent it can possibly be. To make sure that the clever among us don't bother to try to fix things when we get stranded. Where do you want to go today? A three hour tour, a three hour tour.
8.Rule of Robustness: Robustness is the child of transparency and simplicity. 'Nuff said.
9.Rule of Representation: Fold knowledge into data so program logic can be stupid and robust. As opposed to making the data as complicated as possible, without neglecting to make the program logic as confusing as possible. Oh, and the logic is built on a bloated, error prone framework. Can the code be more verbose? Can we make some more libraries that get utilized by about 30%? As opposed to Perl. Clean, logical design. You don't have to wonder what that call does or look it up. You know because there aren't a bunch of useless calls that make it 'easier' to do simple things.
10.Rule of Least Surprise: In interface design, always do the least surprising thing. As opposed to always interrupting the user while they try to do their work. And putting the most commonly used menu options at the somewhere in the lower bottom of the dropdown. Or putting them on toolbars that swallow most of the work area in the form of confusing icons, which most users accidentally move by themselves, and then can't find again. Nor can the Systems Administrators sometimes.
11.Rule of Silence: When a program has nothing surprising to say, it should say nothing. Hear that Clippy? Hear that balloon generating obnoxious freaking software developers?
12.Rule of Repair: When you must fail, fail noisily and as soon as possible. Well, I will not even start down this road, except to say that the sure way to insure your users will never in the least understand the concepts behind how their system works is to hide most crashes and errors, and only at illogical times to make them click through windows with a completely useless error code or message displayed.
13.Rule of Economy: Programmer time is expensive; conserve it in preference to machine time. Our industry long ago left these concerns behind, how else can they drive the hardware market? The more bloated the software, the more users will run screaming to a retail outlet.
14.Rule of Generation: Avoid hand-hacking; write programs to write programs when you can. The problem is, if your programs aren't flexible, like small useful tools, you have no choice but to do everything manually.
15.Rule of Optimization: Prototype before polishing. Get it working before you optimize it. Would that solve the over-designing problems we have? It would go a long way. Why over conceptualize? The small tools concept is much harder than a huge, whoop de doo design.
16.Rule of Diversity: Distrust all claims for "one true way". Wow, a choice, what a concept that is.
17.Rule of Extensibility: Design for the future, because it will be here sooner than you think. If you don't want to force users into an arbitrary upgrade cycle, that is.
These rules are borrowed from ESR without permission. He has more guns than me, I could be in trouble. His quote is worth repeating:
" If you're new to Unix, these principles are worth some meditation. Software-engineering texts recommend most of them; but most other operating systems lack the right tools and traditions to turn them into practice, so most programmers can't apply them with any consistency. They come to accept blunt tools, bad designs, overwork, and bloated code as normal - and then wonder what Unix fans are so annoyed about." Selah.
1.Rule of Modularity: Write simple parts connected by clean interfaces. Hah! Microsoft says they write simple big software. It's not simple, it's big, and it's not clean.
2.Rule of Clarity: Clarity is better than cleverness. Unfortunately I see neither in modern software.
3.Rule of Composition: Design programs to be connected to other programs. Well, sometimes their programs connect to other programs. In the most unnatural obfuscated way possible. Let's make the software connections as brittle as possible, and provide no way around when it breaks.
4.Rule of Separation: Separate policy from mechanism; separate interfaces from engines. Do we let the mechanism dictate policy? Often. Do we let engines define the interface? The real problem seems to be creating engine work just so we can have even more features in the interface. And creating more mechanisms to mold to our policy.
5.Rule of Simplicity: Design for simplicity; add complexity only where you must. When was the last time something was simple?
6.Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do. As opposed to writing a big program so ours can be bigger than theirs.
7.Rule of Transparency: Design for visibility to make inspection and debugging easier. Well, old binary only, propietary design Microsoft is at the other end of the spectrum. Put 2" thick titanium plating over the windows, and weld shut all ventilation shafts. They've done an amazing job at making the software world the least transparent it can possibly be. To make sure that the clever among us don't bother to try to fix things when we get stranded. Where do you want to go today? A three hour tour, a three hour tour.
8.Rule of Robustness: Robustness is the child of transparency and simplicity. 'Nuff said.
9.Rule of Representation: Fold knowledge into data so program logic can be stupid and robust. As opposed to making the data as complicated as possible, without neglecting to make the program logic as confusing as possible. Oh, and the logic is built on a bloated, error prone framework. Can the code be more verbose? Can we make some more libraries that get utilized by about 30%? As opposed to Perl. Clean, logical design. You don't have to wonder what that call does or look it up. You know because there aren't a bunch of useless calls that make it 'easier' to do simple things.
10.Rule of Least Surprise: In interface design, always do the least surprising thing. As opposed to always interrupting the user while they try to do their work. And putting the most commonly used menu options at the somewhere in the lower bottom of the dropdown. Or putting them on toolbars that swallow most of the work area in the form of confusing icons, which most users accidentally move by themselves, and then can't find again. Nor can the Systems Administrators sometimes.
11.Rule of Silence: When a program has nothing surprising to say, it should say nothing. Hear that Clippy? Hear that balloon generating obnoxious freaking software developers?
12.Rule of Repair: When you must fail, fail noisily and as soon as possible. Well, I will not even start down this road, except to say that the sure way to insure your users will never in the least understand the concepts behind how their system works is to hide most crashes and errors, and only at illogical times to make them click through windows with a completely useless error code or message displayed.
13.Rule of Economy: Programmer time is expensive; conserve it in preference to machine time. Our industry long ago left these concerns behind, how else can they drive the hardware market? The more bloated the software, the more users will run screaming to a retail outlet.
14.Rule of Generation: Avoid hand-hacking; write programs to write programs when you can. The problem is, if your programs aren't flexible, like small useful tools, you have no choice but to do everything manually.
15.Rule of Optimization: Prototype before polishing. Get it working before you optimize it. Would that solve the over-designing problems we have? It would go a long way. Why over conceptualize? The small tools concept is much harder than a huge, whoop de doo design.
16.Rule of Diversity: Distrust all claims for "one true way". Wow, a choice, what a concept that is.
17.Rule of Extensibility: Design for the future, because it will be here sooner than you think. If you don't want to force users into an arbitrary upgrade cycle, that is.
These rules are borrowed from ESR without permission. He has more guns than me, I could be in trouble. His quote is worth repeating:
" If you're new to Unix, these principles are worth some meditation. Software-engineering texts recommend most of them; but most other operating systems lack the right tools and traditions to turn them into practice, so most programmers can't apply them with any consistency. They come to accept blunt tools, bad designs, overwork, and bloated code as normal - and then wonder what Unix fans are so annoyed about." Selah.
Comment on this post [ so far] ... more like this: [foo]