ramesh was here

"People are often frustrated by technology when it fails. Although operating systems such as Windows have become much more stable, there are still many security holes exploited every day. For a non-programmer, these issues are mysteries: the machine that never makes mistakes is full of problems, and who knows why?

Programmers, on the other hand, are familiar with the limits of the machine--what happens inside the computer when it takes several minutes to open large files, why a particular security hole is a problem, and why it's so difficult to get large-scale software projects right.

They understand it because they've dealt with most of these issues in their own programs and work with the ``stuff'' of the machine (to varying degrees across different programming languages). This can lead to some exciting finds, such as realizing how you can earn thousands of dollars in Windows solitaire set to Las Vegas style. Maybe not as good as earning real money, but how many of your friends have made $32K on under an hour playing cards?

In sum, programming lets you work with your mind to free yourself to create things that are interesting or useful instead of being limited by the confines of what others have done before, and even when using those other things, you'll find that you can better appreciate and understand them."

novice

• puts "#include <stdio.h>" in his code, but is not sure why
  
• has heard of pointers, but has never seen one

user

• uses the following macros:

  #define BEGIN   { 
  #define END     ;}
  

• has had a bad experience with pointers
• knows the difference between ' and "

knowledgeable user

• uses:
  

  if(a==b) c = 1; else c = 0;

  
  


• uses pointers, but only in place of arrays
  
• loves writing code on Windows

expert

• uses:

  c = (a==b) ? 1 : 0;
  

  
  
• uses pointers comfortably
  
• are jazzed when they find a compiler bug because they found it
  
• has figured out what && and || are for
  
• refuses to write C code on Windows

hacker

• uses:

  c = a==b;
  

  
  
• writes code which use pointers to functions
  
• writes macros instead of simple functions
  
• uses bitwise operators because they are like assembler
  
• writes simple code with "cat >" and compiles it with "!cc".
  
• uses argv and argc

guru

• avoids bitwise operators due to portability
  
• are annoyed with compiler bugs
  
• writes code portable enough to port from VMS but doesn't relish the
  thought
  
• writes libraries that his fellow workmates use
  
• can answer most C questions after a little thought

wizard

• writes compilers with "cat >" (and they work!)
  
• reads device driver source with breakfast
  
• can tell what question you are about to ask, and answer it
  
• is on a first-name basis with Dennis, Bill, and Ken

Source

"This is a relatively uncommon fetish, however so far I've found a few men in the UK that will admit to it, or share it. The descriptions below are partly intended to answer questions that are usually fired at me online in part. My own website network answers other questions. I hope there are like minded folks out there who might add to this in the future. The techniques can be generalised to trucks, motorbikes, boats, construction vehicles (I also enjoy these too) according to taste :-)."

A Programmer's Progress: Why Software Doesn't Work in 14 Words or Less:
By Paul Epps

This is Weinberg's Zeroth Law of Software: If the software doesn't have to work, you can always meet any other requirement.

--- Gerald M. Weinberg, Quality Software Management, Volume 1: Systems Thinking


The last two development projects I've worked on have had one thing in common: We charged the client a pile of money and delivered basically nothing of any utility.

Another way to look at it: We met all the requirements by delivering software that didn't work.

In one case, the client was big enough and flush enough to be able to weather a multi-million dollar misadventure and remain solvent.

In the other case, the client was a dot-com startup, wasn't able to take that kind of a pounding, and had to go out of business.

That summarizes my recent contribution to the software industry.
Mediocrity is Seductive

The quality of the work being done at our shop — and at many other shops — is very poor, our project success rate is approximately 0.0 percent, the tools and techniques we're using have been proven not to work, at least in the way that we're using them, and yet any suggestion that we might want to try something different, with an eye towards improvement, is met with incredible resistance.

Why is that?

Well, I have to admit that even I get a certain comfort level from the abysmally low expectations we've established for ourselves, both internally and on the part of clients.

The fact that no one really expects the software to actually work is, as Weinberg's Law predicts, an incredible simplifying factor.

Clearly we could do better, but there might be some actual effort involved, and since no one expects better anyway, why bother?

High Failure Rates on the Web

. . . when public website users perform simple Internet tasks, they're successful two-thirds of the time on average. In other words, users fail 35% of the time . . .

Six sigma tolerates no more than 3.4 defects per million manufacturing opportunities; in contrast, the Web generates 350,000 defects per million interaction opportunities. The difference between the two quality levels is a factor of 100,000.

--- Jakob Nielsen, "Two Sigma: Usability and Six Sigma Quality Assurance"

That should be enough to embarrass and/or disgust anyone in our business — with the exception of those people incapable of being embarrassed or disgusted — who wasn't embarrassed or disgusted already by the current pathetic state of web development.
Weinberg's Law Revisited

This is Weinberg's Zeroth Law of Software: If the software doesn't have to work, you can always meet any other requirement.
--- Gerald M. Weinberg

In what sense can something be said to "work" if it fails 35 percent of the time?

The only reason the Web works at all is that people are flexible and persistent enough to try again when their first attempt fails.

The good news, I suppose, is that the opportunity for improvement is virtually limitless.

To anyone out there who still cares, I would say this: Learn something! Make a daily effort to get better.

If you're a manager, learn something and give your team opportunities to learn and grow. Hold the line on quality standards. Let people know that the work they're doing is important and that doing it well is worth something.

Source:

"Weinberg's Law of Twins states that most of the time, no matter how much effort one expends, no event of any great significance will result. Weinberg's Law of Twins Inverted states that occasionally—particularly when one isn't expecting it—a significant event occurs. Gerald Weinberg invented the law and described it in his book The Secrets of Consulting (1986), in which he explains the origin of its name.

Weinberg reported that, while riding a bus in New York City, he observed a mother with eight small children embark. She asked the driver the amount of the fare; he told her that the cost was thirty-five cents, but that children under the age of five could ride for free. When the woman deposited only thirty-five cents into the payment slot, the driver was incredulous. 'Do you mean to tell me that all your children are under five years old?' The woman explained that she had four sets of twins. The driver replied, 'Do you always have twins?' 'No,' said the woman, 'most of the time we don't have any.'"