 |
| As you can tell I am soooo lucky to have met my wonderful wife! Of course, it helps that she is a geek too. She is an PE ME and she has been putting up with my cluelessness for nearly 40 years. |
Jan 7, 2015
Web Comic #2
The good folks at readwrite.com have posted the next episode of the web comic based on good old grumpy me! It is about my life as a clueless noob...
Dec 15, 2014
Did you answer the question I asked?
The last cartoon told the story of a meeting that was trying to deal with a broken schedule but the real story is about broken communication. People hear what they expect to hear. If I ask you a question and you give me an answer that sounds reasonable, I am likely to believe that 1) you understood the question I asked and, 2) you answered the question I asked. That is rarely the case, it is never the case when people are scared. The complete story goes more like this:
I was hired at a company to help them develop a new product line that required a high speed long distance data network. I had been working doing network services research for what was then known as SBC, now known as AT&T, for the last five years and was very much the right guy for the job. (Not to mention that working for the phone company made me so depressed that I had gone to a shrink for help. It was either drugs or leave SBC. I left after I found out that most of the people I worked with were on anti-depressant drugs. Working for a soul sucking evil company is bad for your health.)
After I had been working there for only three or four days I was asked to sit in on a meeting about a project that was running about three months late and that didn't look like it was going to finish any time soon. The project as planned was to take one year. They were now 15 months into the project and were starting to panic.
This was a typical "come to Jesus" meeting where the company president was asking everyone to pledge their lives to the completion of the project. They were told that the future of the company depended on the prompt completion of the project. (In other words they were told that they either had to complete the project soon or find another job.)
After the attempt to scare his employees to death the president went around the room and asked each person to give him a completion date for their part of the project. He spent a lot of time doing this. He made them swear to the dates. Then he turned on one poor engineer who had been working for more than a year trying to solve a critical technical problem. The problem had to be solved to get the performance they were planning for. Failling to solve the problem would make the system run 50% slower. Worse than that, failing to solve the problem might mean that the process could never be made faster. That was not acceptable. They had to make it faster.
The mistake of making one highly competent person responsible for the most critical part of a project is more serious than it sounds. It puts tremendous pressure on that person. If they fail, the whole project fails. The stress can ruin a great engineer. Everyone needs to have the support of a team and feel that they can always ask for help and get help if they need it. Even the most hard core lone wolf (like me when I was younger) needs to know they can go to management and ask for help without getting put down or beat down. The worse thing that management can do is to say something like "YOU! need help? Gee, I guess you aren't as good as we thought you were." You might as well just carve their heart out and leave them dead on the side of the road. Of course, it does give the manager a perfect scape goat when the project fails.
At the end of the meeting the president turned to me and explained "I know you are not part of this project, but I want your opinion of the new schedule". "Oh shit", I thought. This is the time to either lie or lose any chance I had of making friends here. I decided to tell the truth because I wanted to work there a long time. Better to be truthful with management than to make friends. (I wound up leaving after only nine months, just ahead of the lay off that got everyone over 40.)
The situation in the meeting was particularly touchy because I was in my late 40s and most of the people in the room were in their late 20s and early 30s. They all had graduate degrees. They had been out of school for only a few years. Most of them had degrees from schools I couldn't even dream of going to. Almost all of them were from rich families, I was not. I was 15 years older than the president of the company. The age and social class structure of the group was out of whack. That all matters more than you might think.
The project was months over due and the engineers had just committed to finishing it in four months. I was being asked to tell them if this would happen or not. I said, "no one asked any questions about how long it was going to take to test the system and integrate it into the production environment". The president looked at me oddly and so did everyone else. I went on to the president "You were asking when the system would be in production and generating revenue. But, the engineers were talking about when development would be complete". You see folks, the question they heard was "When will you be done?" but the president was asking "When will is start making money?". The engineers all agreed with me. They were telling the president when development would be complete, not when the system would go into production.
I went on, "Also, there is no plan for what to do if the performance problem is not solved. You need to have a plan in place in case the problem is not solved. How do you know when to punt and go with the lower performance?" The engineer responsible for solving the problem looked damned angry at that point. Tight lips, white edges around the mouth and eyes. I said to her "I am not saying you can not solve the problem. I am saying that it might not get solved in time for this system." That calmed her down a bit.The real problem was that management had never considered any of the risks involved in the project. They planned for the best possible case and never even considered what to do it something went wrong.
I went on to tell the group that I expected at least a month, mostly likely two months, of testing and performance tuning, and at least a month for integration into the production system. I went on to say that I thought it was likely to take three months after the end of development to get the system into production. All the engineers slowly nodded "yes" the president looked like he was about to blow a vein.
It took three months to get the system into production after the end of development.
I talked to the president privately. He thought they had all been lying to him. I tried to explain that they had been perfectly truthful, but they were not hearing the question he was asking. They were hearing the question they thought he was asking. And, they answered that question with perfect honesty. The president could not accept that idea. He lost trust in his development staff.
How come I could spot the problems in the meeting? I spent four years working at the help desk at my university as an undergraduate where I got a lot of experience figuring out what people were actually saying. After school various corporations put me through listening training, requirements gathering training, and interviewing training. I have been a manager and an engineers and seen the same problem in meetings I've been in before. I have seen the problem from both sides and saw the terrible results. You can sum it up as "been trained, been there, done that, have the scars to prove it".
I was hired at a company to help them develop a new product line that required a high speed long distance data network. I had been working doing network services research for what was then known as SBC, now known as AT&T, for the last five years and was very much the right guy for the job. (Not to mention that working for the phone company made me so depressed that I had gone to a shrink for help. It was either drugs or leave SBC. I left after I found out that most of the people I worked with were on anti-depressant drugs. Working for a soul sucking evil company is bad for your health.)
After I had been working there for only three or four days I was asked to sit in on a meeting about a project that was running about three months late and that didn't look like it was going to finish any time soon. The project as planned was to take one year. They were now 15 months into the project and were starting to panic.
This was a typical "come to Jesus" meeting where the company president was asking everyone to pledge their lives to the completion of the project. They were told that the future of the company depended on the prompt completion of the project. (In other words they were told that they either had to complete the project soon or find another job.)
After the attempt to scare his employees to death the president went around the room and asked each person to give him a completion date for their part of the project. He spent a lot of time doing this. He made them swear to the dates. Then he turned on one poor engineer who had been working for more than a year trying to solve a critical technical problem. The problem had to be solved to get the performance they were planning for. Failling to solve the problem would make the system run 50% slower. Worse than that, failing to solve the problem might mean that the process could never be made faster. That was not acceptable. They had to make it faster.
The mistake of making one highly competent person responsible for the most critical part of a project is more serious than it sounds. It puts tremendous pressure on that person. If they fail, the whole project fails. The stress can ruin a great engineer. Everyone needs to have the support of a team and feel that they can always ask for help and get help if they need it. Even the most hard core lone wolf (like me when I was younger) needs to know they can go to management and ask for help without getting put down or beat down. The worse thing that management can do is to say something like "YOU! need help? Gee, I guess you aren't as good as we thought you were." You might as well just carve their heart out and leave them dead on the side of the road. Of course, it does give the manager a perfect scape goat when the project fails.
At the end of the meeting the president turned to me and explained "I know you are not part of this project, but I want your opinion of the new schedule". "Oh shit", I thought. This is the time to either lie or lose any chance I had of making friends here. I decided to tell the truth because I wanted to work there a long time. Better to be truthful with management than to make friends. (I wound up leaving after only nine months, just ahead of the lay off that got everyone over 40.)
The situation in the meeting was particularly touchy because I was in my late 40s and most of the people in the room were in their late 20s and early 30s. They all had graduate degrees. They had been out of school for only a few years. Most of them had degrees from schools I couldn't even dream of going to. Almost all of them were from rich families, I was not. I was 15 years older than the president of the company. The age and social class structure of the group was out of whack. That all matters more than you might think.
The project was months over due and the engineers had just committed to finishing it in four months. I was being asked to tell them if this would happen or not. I said, "no one asked any questions about how long it was going to take to test the system and integrate it into the production environment". The president looked at me oddly and so did everyone else. I went on to the president "You were asking when the system would be in production and generating revenue. But, the engineers were talking about when development would be complete". You see folks, the question they heard was "When will you be done?" but the president was asking "When will is start making money?". The engineers all agreed with me. They were telling the president when development would be complete, not when the system would go into production.
I went on, "Also, there is no plan for what to do if the performance problem is not solved. You need to have a plan in place in case the problem is not solved. How do you know when to punt and go with the lower performance?" The engineer responsible for solving the problem looked damned angry at that point. Tight lips, white edges around the mouth and eyes. I said to her "I am not saying you can not solve the problem. I am saying that it might not get solved in time for this system." That calmed her down a bit.The real problem was that management had never considered any of the risks involved in the project. They planned for the best possible case and never even considered what to do it something went wrong.
I went on to tell the group that I expected at least a month, mostly likely two months, of testing and performance tuning, and at least a month for integration into the production system. I went on to say that I thought it was likely to take three months after the end of development to get the system into production. All the engineers slowly nodded "yes" the president looked like he was about to blow a vein.
It took three months to get the system into production after the end of development.
I talked to the president privately. He thought they had all been lying to him. I tried to explain that they had been perfectly truthful, but they were not hearing the question he was asking. They were hearing the question they thought he was asking. And, they answered that question with perfect honesty. The president could not accept that idea. He lost trust in his development staff.
How come I could spot the problems in the meeting? I spent four years working at the help desk at my university as an undergraduate where I got a lot of experience figuring out what people were actually saying. After school various corporations put me through listening training, requirements gathering training, and interviewing training. I have been a manager and an engineers and seen the same problem in meetings I've been in before. I have seen the problem from both sides and saw the terrible results. You can sum it up as "been trained, been there, done that, have the scars to prove it".
Dec 12, 2014
I've never been a cartoon before!
Seems like some people think my writing is actually interesting. The folks at ReadWrite.com decided to make a cartoon based on me, yours truly, the grumpy programmer. You can see the whole article or just look at the pictures right here.
Talk about how to inflate my already inflated ego!
Talk about how to inflate my already inflated ego!
Dec 10, 2014
Why is the Next Big Thing always Ancient History?
Recently I've been
seeing a lot of hype about the Internet of Things (IoT). It is
clearly the next big thing. A brand new idea that is going to change
all our lives for the better. No doubt it will. I've been talking
about the day when the refrigerator will track its contents and the
age of everything in it for so long I can't even mention the idea to
my wife without getting an eye roll and a glazed look. I think she
got bored with the idea sometime in the '70s.... But, really wouldn't
it be great if the refrigerator and the pantry would keep track of
what was in them and generate shopping lists for me? How about being
able to suggest a nice dinner menu using only stuff on hand? I'm
still looking forward to that!
But, IoT is the next big thing, how could anyone have been talking about it for 30+ years? Well, it was kind of obvious that something like this would happen. After all, have you seen a picture of a robotic manufacturing plant? Do you think those robots aren't on a network? Networked "things" go back to the early days before Ethernet and Internet technology. Take a look at the history of the Internet Coffee Pot from 1991. No, that is not from before Ethernet, or Internet, but it gets the idea across. The idea of smart things has been floating around for at least 30 years, and really for a lot longer than that.
Are printers smart things? They have been networked since at least the early '80s.
Take the case of Google Goggles (Yes, I know the are called Google Glasses, but seriously... Try saying "Google Goggles" ten times fast. If you don't end up saying "goo goo" or "goo gah" you are a better man than I. Better yet, try that while doing your best imitation of a goose. Not suitable for work!) OK, clearly Google Goggles are another candidate for next big thing. Turns out that its ancestors go all the way back to Ivan Sutherland's head mounted display (Google for pictures) from 1968. The idea behind Google Goggles is at least 50 years old.
The examples of old ideas that became the next big thing go on and on. Remember how big and important SVG (Scaled Vector Graphics) was back around the turn of the century? They were the coolest thing since 7-Eleven started selling Ripple the refrigerator case. My boss at the time, a brilliant Electrical Engineer, who was for some reason working on designing software. (EE design skills do not always transfer well to software, a function call is not a cable even if they both transfer data. Software skills do not transfer to electronics well either; Is a picofarad a real thing? Really?) Well, she was excited about SVG. She had read all about if and had been told by many people that it was the coming thing and we, for some reason I never heard, had to be on top of it. She came into my cube and told me to research SVG in depth. I asked, what do you want to know and why is it such a big deal? I told her that once the tool set settled down it was something that only artists were going to have to worry about. She not only didn't believe me. She got pretty angry.
After she settled down I made the mistake of saying that SVG is not new and it is no big deal. It was the kind of graphics I did as an undergrad and had coded up several times for different projects. SVG is nothing but 2D computer graphics with a 3x3 matrix and shading all wrapped up in a standard file format. No Big Whoop! I implemented all of that, including elliptical and spline curves on a 68000 in assembly language back in '85. It was old hat, undergraduate level stuff in the early '70s. Again, the next big thing was more than 30 years old. She was totally befuddled by my reaction. But, then one of the reasons I was hired was because of my experience in computer graphics. (Algorithms, not tools.)
How does some ancient idea or technology become the next big thing? Why does this happen again and again and again?
It happens to me because I am old enough to remember, curious enough to read, have a weird memory, and an over active imagination. Seriously, I am not normal. The thing is that this stuff is new to most people. When someone tells you something is new, and it is new to you, why shouldn't you believe them? The obvious answer is that people pushing the next big thing are trying to get rich and will lie like a rug to get there. Been there, almost done that. Another reason is that enthusiasm is infectious. It is just fun to jump on something that seems new and exciting. But, mostly the media have little to write about so they all jump on the same new idea and hype it.
No... that is not what I mean by why does this happen. I mean, why is it that something that was dreamed up, developed, and used 50 years ago can be the Next Big Thing?
The answer can be summed up, but not explained, by a quotation from Robert A. Heinlein in the book "The Door into Summer":
Think about Google Goggles versus Ivan Sutherland's head mounted display. In the late '60s the HMD was at the hairy edge of what was technologically possible. The displays used video tubes. The joke was that it was a great idea as long as you don't mind having 20,000 volts across your temples. The displays in Google Goggles were not even science fiction in 1968. Comparing the computer in Google Goggles with the computer used by the heads up display is, well impossible. Moore's law says that our ability to put transistors on a chip has increased by more than a million fold since the heads up display was built. Head position was determined using a huge mechanical gizmo call the Sword of Damocles. In Google Goggles head position is tracked using micro machine accelerometers and gyros. Technology that wasn't even possible in the middle sixties. The fact is that while Ivan Sutherland's head mounted display demonstrated the wonderful potential of something like Google Goggles, at the time it was built it did not, and could not, meet any of the requirements to be widely used. It wasn't time to railroad yet. Now it is, we can build Google Goggles.
I actually saw Ivan's HMD. I went to the University of Utah for both undergraduate and graduate school. One day I was sent to get something out of a storage room. Way in the back of the room was this weird looking pile of equipment. It looked like a prop from a '50s era science fiction movie. I got what I was sent for and then asked around to find out what that pile of stuff was. Someone recognized it and told me about it. We went back to the storage room and he explained the whole thing. Later I was able to see videos of the thing being used. It made me really think. I think too much progress is blocked by a failure of imagination. Sutherland has a lot of imagination and the ability to make it real.
SVG was a very different situation. All the technology for SVG has existed since at least sometime in the '60s. The concepts and techniques behind SVG were well known, widely taught, and used all over the world. But, it was known, taught, and used by a tiny number of people. There was no demand for an SVG standard until computer graphic technology became cheap enough for a large number of people to be using it. There was no demand until there was a need to transmit art over a network. There was no demand until there was a need to dynamically scale art for many different types and sizes of displays. Once all those factors came into play it seemed like SVG popped up almost overnight. It had been lurking in the background and suddenly became visible to the whole world when the need for it emerged. SVG seemed like a new thing, but to old computer graphics hands it was nothing to get excited about.
The effect of the law on the next big thing is unappreciated by most techies. We tend to look only at the technology and not at the legal environment that lets us, or stops us, from building a service. I did a quick check on the web for the history of the Internet. I found lots of pages that talked about the history of the technology. One even mentions Sputnik and the cold war as driving forces behind the Internet. But, not one of them mentioned the nearly 100 years of legal theory, law making, and litigation, that created the legal environment that let people own modems, connect those modems to the telephone network, and then connect to the Internet without having to pay per minute to use the phone line.
If the law did not force AT&T to charge a fixed monthly fee for local telephone calls then using the Internet over the phone lines would have cost hundreds of dollars per day. In most countries all phone calls were billed by the minute and that policy kept the Internet from reaching far outside of the US until that changed. If the law did not force AT&T to let you own your own telephone equipment, let you connect that equipment to their network, and use that equipment to connect to the Internet it would have been impossible for most people to afford to use the Internet. No consumer friendly laws, no Internet. And, believe me, the phone companies, all of them, hate the Internet because they cannot control it.
It wasn't that long ago that the law was not on our side. That changed and we got the Internet. The big telecoms are trying, successfully so far, to change the law back to favoring them. If you like the Internet, you need to take action to protect the laws that govern the Internet. Call you representative and demand that net neutrality stay the law of the land.
The key thing to remember about the Internet is that the technology was developed and in use by the government and the military for nearly 20 years before the law was changed to let you use that technology. The Internet was old hat for some of us long before it became the next big thing. if you really want to get into something interesting, try finding out about the Top Secret patent system. Scary stuff. Technologists, and people who depend on technology, that is all of us, need to understand and get involved with the law.
But, IoT is the next big thing, how could anyone have been talking about it for 30+ years? Well, it was kind of obvious that something like this would happen. After all, have you seen a picture of a robotic manufacturing plant? Do you think those robots aren't on a network? Networked "things" go back to the early days before Ethernet and Internet technology. Take a look at the history of the Internet Coffee Pot from 1991. No, that is not from before Ethernet, or Internet, but it gets the idea across. The idea of smart things has been floating around for at least 30 years, and really for a lot longer than that.
Are printers smart things? They have been networked since at least the early '80s.
Take the case of Google Goggles (Yes, I know the are called Google Glasses, but seriously... Try saying "Google Goggles" ten times fast. If you don't end up saying "goo goo" or "goo gah" you are a better man than I. Better yet, try that while doing your best imitation of a goose. Not suitable for work!) OK, clearly Google Goggles are another candidate for next big thing. Turns out that its ancestors go all the way back to Ivan Sutherland's head mounted display (Google for pictures) from 1968. The idea behind Google Goggles is at least 50 years old.
The examples of old ideas that became the next big thing go on and on. Remember how big and important SVG (Scaled Vector Graphics) was back around the turn of the century? They were the coolest thing since 7-Eleven started selling Ripple the refrigerator case. My boss at the time, a brilliant Electrical Engineer, who was for some reason working on designing software. (EE design skills do not always transfer well to software, a function call is not a cable even if they both transfer data. Software skills do not transfer to electronics well either; Is a picofarad a real thing? Really?) Well, she was excited about SVG. She had read all about if and had been told by many people that it was the coming thing and we, for some reason I never heard, had to be on top of it. She came into my cube and told me to research SVG in depth. I asked, what do you want to know and why is it such a big deal? I told her that once the tool set settled down it was something that only artists were going to have to worry about. She not only didn't believe me. She got pretty angry.
After she settled down I made the mistake of saying that SVG is not new and it is no big deal. It was the kind of graphics I did as an undergrad and had coded up several times for different projects. SVG is nothing but 2D computer graphics with a 3x3 matrix and shading all wrapped up in a standard file format. No Big Whoop! I implemented all of that, including elliptical and spline curves on a 68000 in assembly language back in '85. It was old hat, undergraduate level stuff in the early '70s. Again, the next big thing was more than 30 years old. She was totally befuddled by my reaction. But, then one of the reasons I was hired was because of my experience in computer graphics. (Algorithms, not tools.)
How does some ancient idea or technology become the next big thing? Why does this happen again and again and again?
It happens to me because I am old enough to remember, curious enough to read, have a weird memory, and an over active imagination. Seriously, I am not normal. The thing is that this stuff is new to most people. When someone tells you something is new, and it is new to you, why shouldn't you believe them? The obvious answer is that people pushing the next big thing are trying to get rich and will lie like a rug to get there. Been there, almost done that. Another reason is that enthusiasm is infectious. It is just fun to jump on something that seems new and exciting. But, mostly the media have little to write about so they all jump on the same new idea and hype it.
No... that is not what I mean by why does this happen. I mean, why is it that something that was dreamed up, developed, and used 50 years ago can be the Next Big Thing?
The answer can be summed up, but not explained, by a quotation from Robert A. Heinlein in the book "The Door into Summer":
“When railroading time comes you can railroad—but not before.”
Read the book, it is a good read. I have had several cats that actually looked for the door into summer, or dry weather, but I've never had to follow the cat to more than three doors. As sagacious as the quotation is, it is not an explanation of the effect. What the quotation is saying is that no matter when the idea was first thought up you do not get to build railroads, or anything else, until several problems are solved. Some of the problems are listed below.- The Technology has to exist. If you do not know how to make steel and steam engines you do not build steam engines that run on steel rails. If you can't build a wireless network you do not build wi-fi enabled coffee pots.
- It has to be Cheap enough. You have to be able to make a profit off of your new product even when competing with existing products. Smart coffee pots have to compete with dumb coffee pots. Railroads had to compete with wagons and roads.
My first Ethernet card cost more that $100 and I put it into a computer that cost over $1000. To build and Internet enabled coffee pot the cost of a wi-fi port + processor + RAM had to drop down to just a few dollars. Very few people will pay over a thousnad dollars for a smart Mr. Coffee. - It has to be Usable. If there were not already millions of network enabled smart phones in the world a network enabled coffee pot would be pretty useless. The IoT people have it easy. The user interface device is already ubiquitous and well understood by potential customers. The networks needed to make them possible already exist. The railroads had to build their user interface, the train stations. Their whole network, the railroads. As well as the telegraph network needed to schedule them.
- It has to be Legal. It seems like the reasonable thing to do when you have a great idea is to patent it. You can license the patent and make a lot of money. Or, not. Most patents are over valued by their owners. The problem is that once something is patented you either have to pay to use it or wait twenty years for the patent to expire.That twenty year wait is a major brake on the rate of progress.
The other legal problem is the existence of actual laws that make it illegal to do what you want to do. Look at the problem Uber is having with local taxi regulations. Not to mention new laws banning them because of the alleged actions of some of their drivers. - It has to pass the Giggle test. Some ideas just seem silly to people. A product idea cannot succeed if people think it is just plain stupid or impossible. If there had been no Star Trek we still might not have cell phones. To be acceptable an idea has to be acceptable in science fiction. If it can't be accepted in sci-fi it will not be accepted by the public.
- There must be a
Demand for the product. It doesn't matter if your product
meets all the other requirements people have to want what you are
selling. As my MBA ex-brother-in-law once told me "Toilet paper
is the Perfect Product." Everyone one wants it and better yet,
they only use it once. People knew they wanted toilet paper as soon
as they saw it, but we went thousands of years without it.
Think about Google Goggles versus Ivan Sutherland's head mounted display. In the late '60s the HMD was at the hairy edge of what was technologically possible. The displays used video tubes. The joke was that it was a great idea as long as you don't mind having 20,000 volts across your temples. The displays in Google Goggles were not even science fiction in 1968. Comparing the computer in Google Goggles with the computer used by the heads up display is, well impossible. Moore's law says that our ability to put transistors on a chip has increased by more than a million fold since the heads up display was built. Head position was determined using a huge mechanical gizmo call the Sword of Damocles. In Google Goggles head position is tracked using micro machine accelerometers and gyros. Technology that wasn't even possible in the middle sixties. The fact is that while Ivan Sutherland's head mounted display demonstrated the wonderful potential of something like Google Goggles, at the time it was built it did not, and could not, meet any of the requirements to be widely used. It wasn't time to railroad yet. Now it is, we can build Google Goggles.
I actually saw Ivan's HMD. I went to the University of Utah for both undergraduate and graduate school. One day I was sent to get something out of a storage room. Way in the back of the room was this weird looking pile of equipment. It looked like a prop from a '50s era science fiction movie. I got what I was sent for and then asked around to find out what that pile of stuff was. Someone recognized it and told me about it. We went back to the storage room and he explained the whole thing. Later I was able to see videos of the thing being used. It made me really think. I think too much progress is blocked by a failure of imagination. Sutherland has a lot of imagination and the ability to make it real.
SVG was a very different situation. All the technology for SVG has existed since at least sometime in the '60s. The concepts and techniques behind SVG were well known, widely taught, and used all over the world. But, it was known, taught, and used by a tiny number of people. There was no demand for an SVG standard until computer graphic technology became cheap enough for a large number of people to be using it. There was no demand until there was a need to transmit art over a network. There was no demand until there was a need to dynamically scale art for many different types and sizes of displays. Once all those factors came into play it seemed like SVG popped up almost overnight. It had been lurking in the background and suddenly became visible to the whole world when the need for it emerged. SVG seemed like a new thing, but to old computer graphics hands it was nothing to get excited about.
The effect of the law on the next big thing is unappreciated by most techies. We tend to look only at the technology and not at the legal environment that lets us, or stops us, from building a service. I did a quick check on the web for the history of the Internet. I found lots of pages that talked about the history of the technology. One even mentions Sputnik and the cold war as driving forces behind the Internet. But, not one of them mentioned the nearly 100 years of legal theory, law making, and litigation, that created the legal environment that let people own modems, connect those modems to the telephone network, and then connect to the Internet without having to pay per minute to use the phone line.
If the law did not force AT&T to charge a fixed monthly fee for local telephone calls then using the Internet over the phone lines would have cost hundreds of dollars per day. In most countries all phone calls were billed by the minute and that policy kept the Internet from reaching far outside of the US until that changed. If the law did not force AT&T to let you own your own telephone equipment, let you connect that equipment to their network, and use that equipment to connect to the Internet it would have been impossible for most people to afford to use the Internet. No consumer friendly laws, no Internet. And, believe me, the phone companies, all of them, hate the Internet because they cannot control it.
It wasn't that long ago that the law was not on our side. That changed and we got the Internet. The big telecoms are trying, successfully so far, to change the law back to favoring them. If you like the Internet, you need to take action to protect the laws that govern the Internet. Call you representative and demand that net neutrality stay the law of the land.
The key thing to remember about the Internet is that the technology was developed and in use by the government and the military for nearly 20 years before the law was changed to let you use that technology. The Internet was old hat for some of us long before it became the next big thing. if you really want to get into something interesting, try finding out about the Top Secret patent system. Scary stuff. Technologists, and people who depend on technology, that is all of us, need to understand and get involved with the law.
Nov 6, 2014
It's the Users Stupid!
The
phrase "Mechanism not Policy" was the mantra of the X
Windows System developers from day one and still guides everything
they do. I was involved in the X Windows System (hence forth just
"X") during the late '80s and early '90s. I represented a
company on the X Consortium board as well as doing ports of the X
server to several graphics systems. During that time I internalized
the idea of "Mechanism not Policy". But, I rewrote it as
"Tools not Rules".
(To the best of my knowledge I was the first person to port X to run on a frame buffer with 24 bit color and the first to port it to a display greater than 800x600 pixels in size. That was a long time ago in terms of Moore's law.)
The basic idea is that when you are creating a tool you need to keep in mind that you are creating a tool that people will use to solve problems that are important to them. The thing is, you do not, and can not. know what those problems are. People will find surprising uses you never thought of and use the tool to solve problems you could not imagine. That means that you must not, never ever, design the tool with built in limits that restrict what people can do with the tool. The corollary of this concept is that if users, especially if a large number of users, ask for a small modification to make the tool more useful to them then if it is at all possible you should make the change even if you can not see their reason for it. You should make the change even if you disagree with their reasons for asking for it. It is clearly the right way for them to solve their problem.
You are not the measure of all things, your point of view is not the one and only point of view that counts. This concept is summed up in the Platinum Rule, "Do unto others as they would have you do unto them". Compare that to the Golden Rule in which your preferences are assumed to apply to every one else in the entire Universe. A good example of the Platinum Rule is offering someone a drink. I like beer, wine, and a good whiskey. So, by the Golden Rule I should offer those things to people I meet. I have a friend who is an alcoholic, he has been sober for more than 30 years. He does not want me to offer him a drink, he does not want me to drink around him, but by the Golden Rule I should offer him a drink because I like to drink. By the Platinum rule I should never offer him a drink, I should not drink around him, and I should intervene if I see him reaching for something that contains alcohol. Which rule do you think he wants me to follow?
Of course, the Platinum rule can not be used to make you violate your personal moral code or to extract money from you... Gee, I want people to give me money... So, follow the Platinum Rule and give till it hurts! Gee I want you to suck my,.. You must apply some reason to following any rule.
When it comes to adding features to an open source project you do have to be reasonable about adding new features just like you do when you apply the Platinum Rule to dealing with people. People will ask for things that do not belong in the project or that will just require to much time to implement. My first open source project was a thing called the "Input Line Editor" or ILE. I had a couple of people who wanted me to help them convert it into an Ada compiler. These folks really did not see the difference between a simple editor and an Ada compiler. Oh well. I did refuse to make that modification. It would have taken me years and I did not want an ADA compiler.
On the other hand, I got several requests for modifications to ILE and I implemented most of them because they made the tool more useful to more people. The changes even made it more useful for me. I also got a couple of major bug fixes. Both of them for bugs I didn't even know I had. Nothing works as well as peer review.
If you do not know what Free/Libre/Open Source software is please go to the Open Source Initiative for a good definition of Open Source Software (click on the links, you know you want to). If you do not know what is right with it, please read "The Cathedral and the Bazaar" by Eric Raymond. (Seriously, if you have never heard of it I want to know the name of the alien planet you come from!) For the rest of this piece I will just refer to Free/Libre/Open Source software as OSS because that is pretty much what everyone else calls it. I could spend a lot of time ranting about what it really is or what it should be called, but those flame wars have been fought for decades and are still going on somewhere on the 'net. If you must flame someone about all that, please flame someone else.
The underlying philosophy of OSS goes hand in glove with the concept "Tools not Rules". OSS is about freedom. It is about the freedom to use and develop tools. Tools that do not impose arbitrary rules on the people who use them. I believe in freedom. I believe that powerful tools make us more free. I believe that having tools that can not be taken away makes us even more free. OSS provides tools that can not be taken away. Tools that we are free to modify for our own specific use and free to incorporate into new tools. Not everyone who works on OSS agrees with me on any of that.
There are people in the OSS world who believe they have the right to tell you what you can and can not do with the tools they are developing even when the changes needed to make them more powerful would cost them almost nothing.
I used to teach in a local community college. I was a teacher for about 10 years. I reached the rank of Adjunct Professor. If I had been full time I would probably still be teaching. Adjuncts get all the fun and work of being a real professor but none of the pay or benefits.
One class I taught was a basic computer literacy class. Believe it or not many people just out of high school and too many people in their 30s or older need a class to learn how to do email, word processing, spread sheets, and databases. Even though I had used all those tools in business for decades I wound up learning a few things that I didn't know... For instance, did you know that in Excel you can write spread sheets with circular references between the cells? Did you know that you can use that feature to write complex iterative programs entirely in the form of a spread sheet? And, if you have the information tied to a chart the chart will animate as the spread sheet cycles? There is a great demo of this feature that runs the famous "Game of Life" inside Excel. Each cell of the spread sheet is loaded with an expression that implements the actions of a cell in "Life". It is a very handy and very powerful feature. It is very useful to teachers and many other professions.
Another very cool thing about spread sheets is that all those little cells form a very nice dependency graph that makes it really easy to execute spread sheets in parallel across multiple cores. It is much easier to find parallelism in spread sheets than in normal programs. So, in a good spread sheet program, you can get iterative programs and parallel execution with very little work. How cool is that?
Excel lets you write general purpose programs as spread sheets. If you can write programs inside a tool they know people will write programs inside that tool. The first time I saw that was when a customer of the University of Utah Computer Center wrote an entire statistics package as macros in our most popular text editor. Blew my poor little mind.
Why would anyone build a statistics package inside a text editor? Well, he was learning to use the editor, saw the part in the manual that talked about macros, and started playing with them because he thought they were cool. Pretty soon he saw he could do his statistical analysis inside the text editor. When he was done he could type in his numbers, invoke a macro, and get his results appended to the bottom of his file! Totally nuts but it worked great for him. That is the point I am trying to make. It worked great for him. People find their own ways to use technology that works for them. No one has the right to tell them that what they are doing is wrong. You might point out what you think is an easier way. You may point out what you think is a more correct way to do the job. But, is it easier for them, is it correct for them?
For some insane reason (I used to be a victim of this particular insanity) programmers seem to think that a solution that uses less computer time is more efficient than one that uses less human time. This is an insane attitude. Computer time is cheap and it is getting cheaper at an incredible rate. Human time is priceless, at least worth a lot more than a computer. Modern computers spend most of their time in an idle loop doing nothing at all, so why not use some of that time to inefficiently make things more efficient for human beings?
I used that feature of Excel to write quick and dirty programs to illustrate concepts when all my talking, white boarding, and hand waving did not work. One day I whipped up a quick spread sheet to create values from different statistical distributions and put up animated charts of the values being accumulated into nice curves that looked just like the ones you find in text books. I was trying to help my students understand that distributions talk about the properties of a large set of samples, but not much about individual values. For some reason on that night with that group of students I just could not get the idea across any other way. That quick and dirty spread sheet saved the day. After that I started using them all over the place.
One afternoon between semesters I decided to create a series of animated spread sheet charts for use in an upcoming class. I sat down with LibreOffice Calc (the LibreOffice spread sheet program) to do the job. I have moved many spread sheets back and forth between Calc and Excel so I was very surprised when nothing I was trying to do worked. I assumed that I was just not setting some property correctly so I decided to go to the LIbreOffice web site and look up how to do it in Calc. Turns out Calc only has a severely restricted version of the feature. A version that will let you compute VAT in Europe but restricted so that you can not write general iterative programs. I decided to report the problem as a bug. I found that I was not the first to report the bug. I was not the first to report the bug by more than 10 years. I was one of thousands who had reported the bug. The bug is so old that it existed in OpenOffice, the immediate ancestor of LibreOffice, and seems to have existed in StarOffice, the grandfather of LibreOffice.
One of the people who reported the bug was a mechanical engineer who mentioned that most of the engineering disciplines have large suites of spread sheets that do different kinds of analysis. These packages make heavy use of the ability to do iterative programming in a spread sheet. This kind fellow mentioned that the utility of the spread sheets was limited because they can only run on Excel on a PC and they really would love to run them on super computers under the Linux OS. LibreOffice already runs on Linux. Removing the restrictions on the feature would not only benefit a large group of random people, if would benefit the whole world of engineers.
Considering that LibreOffice already has an artificially restricted version of the feature, and considering that if LibreOffice had a full version of the feature it could work its way into every engineering office in the world, you would think that this bug would be at the very top of the list of bugs that need to be fixed. After all, all they have to do is remove the artificial restrictions that keep it from working. Nope, the developers say it is not a bug. Why is it not a bug? Well, the developers say that you should not use a spread sheet that way, you should write a program in a programming language, if you want to do iteration. I am not making this up. I wish I were, but I am not.
The developers are telling the world that they know better than anyone else and they know you should not do that in a spread sheet. It is impossible for me to comprehend the level of arrogance or the lack of caring about other people that lets them have that attitude. It is as if they are deliberately refusing to provide this critical feature to prevent LibreOffice Calc from ever being competitive with Excel. OK, that is a little paranoid, but seriously what reason is there for the developers to prevent people from using Calc the same way they already use Excel?
The LibreOffice developers attitude is unfathomable to me.
The open source philosophy encourages developers to listen carefully to their users. Some times you do have to ignore them. They will ask for ridiculous things. But, we are talking about an important and widely used feature of the most popular commercial spread sheet program in the world. LibreOffice Calc can never be consider as a complete replacement for Excel as long as the ability to write iterative programs is missing.
LibreOffice is not the only OSS project that suffers from the "My way or the Highway" attitude. It is just the one I have the most direct experience with. I do believe that "Tools not Rules" is a better guiding principle.
(To the best of my knowledge I was the first person to port X to run on a frame buffer with 24 bit color and the first to port it to a display greater than 800x600 pixels in size. That was a long time ago in terms of Moore's law.)
The basic idea is that when you are creating a tool you need to keep in mind that you are creating a tool that people will use to solve problems that are important to them. The thing is, you do not, and can not. know what those problems are. People will find surprising uses you never thought of and use the tool to solve problems you could not imagine. That means that you must not, never ever, design the tool with built in limits that restrict what people can do with the tool. The corollary of this concept is that if users, especially if a large number of users, ask for a small modification to make the tool more useful to them then if it is at all possible you should make the change even if you can not see their reason for it. You should make the change even if you disagree with their reasons for asking for it. It is clearly the right way for them to solve their problem.
You are not the measure of all things, your point of view is not the one and only point of view that counts. This concept is summed up in the Platinum Rule, "Do unto others as they would have you do unto them". Compare that to the Golden Rule in which your preferences are assumed to apply to every one else in the entire Universe. A good example of the Platinum Rule is offering someone a drink. I like beer, wine, and a good whiskey. So, by the Golden Rule I should offer those things to people I meet. I have a friend who is an alcoholic, he has been sober for more than 30 years. He does not want me to offer him a drink, he does not want me to drink around him, but by the Golden Rule I should offer him a drink because I like to drink. By the Platinum rule I should never offer him a drink, I should not drink around him, and I should intervene if I see him reaching for something that contains alcohol. Which rule do you think he wants me to follow?
Of course, the Platinum rule can not be used to make you violate your personal moral code or to extract money from you... Gee, I want people to give me money... So, follow the Platinum Rule and give till it hurts! Gee I want you to suck my,.. You must apply some reason to following any rule.
When it comes to adding features to an open source project you do have to be reasonable about adding new features just like you do when you apply the Platinum Rule to dealing with people. People will ask for things that do not belong in the project or that will just require to much time to implement. My first open source project was a thing called the "Input Line Editor" or ILE. I had a couple of people who wanted me to help them convert it into an Ada compiler. These folks really did not see the difference between a simple editor and an Ada compiler. Oh well. I did refuse to make that modification. It would have taken me years and I did not want an ADA compiler.
On the other hand, I got several requests for modifications to ILE and I implemented most of them because they made the tool more useful to more people. The changes even made it more useful for me. I also got a couple of major bug fixes. Both of them for bugs I didn't even know I had. Nothing works as well as peer review.
If you do not know what Free/Libre/Open Source software is please go to the Open Source Initiative for a good definition of Open Source Software (click on the links, you know you want to). If you do not know what is right with it, please read "The Cathedral and the Bazaar" by Eric Raymond. (Seriously, if you have never heard of it I want to know the name of the alien planet you come from!) For the rest of this piece I will just refer to Free/Libre/Open Source software as OSS because that is pretty much what everyone else calls it. I could spend a lot of time ranting about what it really is or what it should be called, but those flame wars have been fought for decades and are still going on somewhere on the 'net. If you must flame someone about all that, please flame someone else.
The underlying philosophy of OSS goes hand in glove with the concept "Tools not Rules". OSS is about freedom. It is about the freedom to use and develop tools. Tools that do not impose arbitrary rules on the people who use them. I believe in freedom. I believe that powerful tools make us more free. I believe that having tools that can not be taken away makes us even more free. OSS provides tools that can not be taken away. Tools that we are free to modify for our own specific use and free to incorporate into new tools. Not everyone who works on OSS agrees with me on any of that.
There are people in the OSS world who believe they have the right to tell you what you can and can not do with the tools they are developing even when the changes needed to make them more powerful would cost them almost nothing.
I used to teach in a local community college. I was a teacher for about 10 years. I reached the rank of Adjunct Professor. If I had been full time I would probably still be teaching. Adjuncts get all the fun and work of being a real professor but none of the pay or benefits.
One class I taught was a basic computer literacy class. Believe it or not many people just out of high school and too many people in their 30s or older need a class to learn how to do email, word processing, spread sheets, and databases. Even though I had used all those tools in business for decades I wound up learning a few things that I didn't know... For instance, did you know that in Excel you can write spread sheets with circular references between the cells? Did you know that you can use that feature to write complex iterative programs entirely in the form of a spread sheet? And, if you have the information tied to a chart the chart will animate as the spread sheet cycles? There is a great demo of this feature that runs the famous "Game of Life" inside Excel. Each cell of the spread sheet is loaded with an expression that implements the actions of a cell in "Life". It is a very handy and very powerful feature. It is very useful to teachers and many other professions.
Another very cool thing about spread sheets is that all those little cells form a very nice dependency graph that makes it really easy to execute spread sheets in parallel across multiple cores. It is much easier to find parallelism in spread sheets than in normal programs. So, in a good spread sheet program, you can get iterative programs and parallel execution with very little work. How cool is that?
Excel lets you write general purpose programs as spread sheets. If you can write programs inside a tool they know people will write programs inside that tool. The first time I saw that was when a customer of the University of Utah Computer Center wrote an entire statistics package as macros in our most popular text editor. Blew my poor little mind.
Why would anyone build a statistics package inside a text editor? Well, he was learning to use the editor, saw the part in the manual that talked about macros, and started playing with them because he thought they were cool. Pretty soon he saw he could do his statistical analysis inside the text editor. When he was done he could type in his numbers, invoke a macro, and get his results appended to the bottom of his file! Totally nuts but it worked great for him. That is the point I am trying to make. It worked great for him. People find their own ways to use technology that works for them. No one has the right to tell them that what they are doing is wrong. You might point out what you think is an easier way. You may point out what you think is a more correct way to do the job. But, is it easier for them, is it correct for them?
For some insane reason (I used to be a victim of this particular insanity) programmers seem to think that a solution that uses less computer time is more efficient than one that uses less human time. This is an insane attitude. Computer time is cheap and it is getting cheaper at an incredible rate. Human time is priceless, at least worth a lot more than a computer. Modern computers spend most of their time in an idle loop doing nothing at all, so why not use some of that time to inefficiently make things more efficient for human beings?
I used that feature of Excel to write quick and dirty programs to illustrate concepts when all my talking, white boarding, and hand waving did not work. One day I whipped up a quick spread sheet to create values from different statistical distributions and put up animated charts of the values being accumulated into nice curves that looked just like the ones you find in text books. I was trying to help my students understand that distributions talk about the properties of a large set of samples, but not much about individual values. For some reason on that night with that group of students I just could not get the idea across any other way. That quick and dirty spread sheet saved the day. After that I started using them all over the place.
One afternoon between semesters I decided to create a series of animated spread sheet charts for use in an upcoming class. I sat down with LibreOffice Calc (the LibreOffice spread sheet program) to do the job. I have moved many spread sheets back and forth between Calc and Excel so I was very surprised when nothing I was trying to do worked. I assumed that I was just not setting some property correctly so I decided to go to the LIbreOffice web site and look up how to do it in Calc. Turns out Calc only has a severely restricted version of the feature. A version that will let you compute VAT in Europe but restricted so that you can not write general iterative programs. I decided to report the problem as a bug. I found that I was not the first to report the bug. I was not the first to report the bug by more than 10 years. I was one of thousands who had reported the bug. The bug is so old that it existed in OpenOffice, the immediate ancestor of LibreOffice, and seems to have existed in StarOffice, the grandfather of LibreOffice.
One of the people who reported the bug was a mechanical engineer who mentioned that most of the engineering disciplines have large suites of spread sheets that do different kinds of analysis. These packages make heavy use of the ability to do iterative programming in a spread sheet. This kind fellow mentioned that the utility of the spread sheets was limited because they can only run on Excel on a PC and they really would love to run them on super computers under the Linux OS. LibreOffice already runs on Linux. Removing the restrictions on the feature would not only benefit a large group of random people, if would benefit the whole world of engineers.
Considering that LibreOffice already has an artificially restricted version of the feature, and considering that if LibreOffice had a full version of the feature it could work its way into every engineering office in the world, you would think that this bug would be at the very top of the list of bugs that need to be fixed. After all, all they have to do is remove the artificial restrictions that keep it from working. Nope, the developers say it is not a bug. Why is it not a bug? Well, the developers say that you should not use a spread sheet that way, you should write a program in a programming language, if you want to do iteration. I am not making this up. I wish I were, but I am not.
The developers are telling the world that they know better than anyone else and they know you should not do that in a spread sheet. It is impossible for me to comprehend the level of arrogance or the lack of caring about other people that lets them have that attitude. It is as if they are deliberately refusing to provide this critical feature to prevent LibreOffice Calc from ever being competitive with Excel. OK, that is a little paranoid, but seriously what reason is there for the developers to prevent people from using Calc the same way they already use Excel?
The LibreOffice developers attitude is unfathomable to me.
The open source philosophy encourages developers to listen carefully to their users. Some times you do have to ignore them. They will ask for ridiculous things. But, we are talking about an important and widely used feature of the most popular commercial spread sheet program in the world. LibreOffice Calc can never be consider as a complete replacement for Excel as long as the ability to write iterative programs is missing.
LibreOffice is not the only OSS project that suffers from the "My way or the Highway" attitude. It is just the one I have the most direct experience with. I do believe that "Tools not Rules" is a better guiding principle.
Subscribe to:
Posts (Atom)