Radu Luchian(ov): Projects: Commentary:
Standards and Specifications

This piece of commentary comes in response to a message (available here), from someone on a discussion list. Normally I would not place it here, but I keep having this discussion with technically-oriented people and I'd like to put the problem up on a larger forum. Whoever is interested and has any comment, by all means, please send it to me!

I apologize for the poor form of this page. I brought it from email. I'll add emphasis and modularize it when I have a chance. Now it's back to work for me smile.

Netizen says: "Standards need strong rules. Specifications need strict guidelines."
Well, I know that's what current authority in both industry and academia say, but I happen to disagree.

Thank you for clearing up the distinction between standards and specifications (henceforth, S&Ses). However, what I was saying refers to both S&Ses. When it comes to humans, I am thoroughly against the "strict" and the "strong" parts of your neat normative statements.

Let's take an example.

IMP is a great web mail project, developed collaboratively. It's user interface is gorgeous and that's why I use it. It has plenty of great functionality, but as you say, it was developed without standards. They put the user first and forgot about basics. Like making sure that messages do get sent :) The client tends to log me off whenever I stay on an individual message more than 5 minutes. So when I compose long messages I have to remember to go back to mailbox view or the moment I press Send I simply lose the message and I don't get any feedback. I lost countless hours of creative work that way (including a more extended previous version of this message). My mistake for moving to IMP out of my beloved Eudora :)

I'm not writing this to illustrate that web mail is bad or that collaborative projects can make horrible mistakes. I'm writing it to showcase the fact that we need both strict S&S and loose S&S. Specifically, wherever automated machine-to-machine transactions are involved, by all means, get the process as strict as you can.

But when dealing with human beings, please try to forget the aging cognitive architectures which present us as logic-based machines. Human beings aren't machines! We make mistakes and we want the software to help us recover from them. We can't remember strict syntax and we want the compiler/IDE designers to understand that. We can't remember the sleuth of variable and function names, with their scopes and raisons d'etre, even for a moderately small project, not to talk about large projects or projects to which we're coming as newbies or after several years. And IDE designers should understand that. We don't have the time and patience to wade through inflexible, crowded user interfaces in order to understand the strict logic of a given designer group. And interface designers in general should understand that. Users need loose stuff. Adaptable stuff, without making the adaptation process a nightmare. That's why I wrote that we need FREEDOM.

I'm strongly against strict/strong S&S wherever users are involved. Developing standards takes lots of resources and it's done in ways that a Psychology textbook would call ecologically invalid. Humans are not good at recalling what they needed at a previous time, nor what they would need ahead of time. Memories are reconstructions greatly influenced by the current context at the time of recall. Models (on which we base our predictions), are [re]constructions too. Both are imperfect that way. As R.A.Heinlein was saying in many of his books, "the most the brightest of us know well, ever, is what they need WHEN they need it. The rest of the people simply deceive themselves that they know stuff" (I'm paraphrasing from Heinlein's book "Friday", which I don't have around right now) So why force tens or millions of users to follow a specific world-view (that of the designer)? My approach would be to provide functionality and teach good principles. I know that (at least on the surface), selling fish is better short-term economically than teaching people how to fish, but as the cluetrain suggests, that's not always true. It puts a tremendous strain on the organization that tries to provide all the fish, or even specific types of niche-fish. History-wise, whenever free knowledge was capped by authority, progress was stalled. I prefer the Web/OpenSource approach of teaching people how to fish for themselves, and continuously learning from them how to fish better.

Normative efforts give me the creeps. They're only useful from a descriptive point of view. Carve a law in stone and it will reflect the day and age, the needs of the time when it was carved. We need functional stuff, not tech-head history books.

I like guidelines, not strict/strong S&Ses. Because some guidelines may contradict or limit others and it's the job of the individual designer, the Art of design (chapeau, Mr.Knuth!), to find the correct balance of guidelines for a specific application.

Natural languages are great because people use them for what they need. If they don't have a word for something, they invent it. That's why the language is a good measure of the culture behind it. Stifle that process (hello, French Academy!), and you stifle creativity.

Same goes for formal languages. Remember Ada? Nice, well-researched, verbose, STRICT language. Who's still using it? How many resources did that project eat away from DARPA? Now compare that with PHP. It started as a home-page-building tool, it used pretty neat guidelines borrowed from various standards, and it grew out of messy collaboration. With lots of feedback from actual users. Who were working on actual projects. With actual needs. Compare how widely spread PHP is with what Ada managed, with all of the dedicated resources behind it. (The comparison is still possible because Ada had 'webbed feet' too: compilers that produce j-code to be run on JavaVirtualMachines). All of the Ada projects listed on HBAP (seemingly abandoned) are very machine-specific and specialized. Why? Because Ada was developed for machines, not people. "It rivals Assembly in efficiency", etc, etc. But we already had a language targeting machines, and of course, C/C++ won the contest, through including or bettering the new functionality Ada was sporting, and through sheer prior distribution.

Netizen says "The Web was fielded witlessly."
Probably. But tell that to the kid who suddenly found an easy way to communicate with others around the world. Or to the out-of-favor politician or philosopher who finally found a low-cost form of publishing world-wide their ideas. I know some companies would have liked to keep the protocols under patent, lock and key, and present some horribly complex XML to the world, but I doubt that would have resulted in the quick adoption HTML saw.

Netizen says "It is easy to be friendly and easy to be strict."
Sure. The tough thing is to do both at the same time. Netizen, if you have a reference to REAL advice on how to do it at the same time, please send it to me. But please note that telling users they can't do what they need to do or that they have to spend months learning how to do it is NOT being friendly.

Netizen says "The customer decides rightly if guided rightly."
So who knows the right way? We or the customer? We know from long and painful experience that they can't communicate their requirements and how messy the system requirement gathering process is. Do WE decide what they want (ahead of time, in big, bulky S&Ses), or do we give them tools to do what they need WHEN they need it?

From http://www.cluetrain.net/
54. "In most cases, neither conversation is going very well. Almost invariably, the cause of failure can be traced to obsolete notions of command and control."

When they happen without the input of their actual users, what are enforced standards other than [soon-to-be-obsolete] notions of command and control?

If you didn't figure it out yet, I read S&Ses as 'ass and asses' :) Because they function like the long-eared mammals on which you gotta use carrots and sticks so they can move your luggage up the mountain. I hope you people enjoy multiple puns as much as I do. ;)


[ Home ][ Current Projects ][ Portfolio ][ Pastime ][ Pseudonyms ][ CV ]