Digilabs Technologies Blog

Archive for the ‘Random Thoughts’ Category

When NASA first started sending up astronauts, they discovered that ball-point pens would not work in zero gravity. However, they still needed a way to write. To combat this problem, NASA scientists went to work, developing a pen that writes in zero gravity. A decade and $12 million later, they came up with a pen that writes in zero gravity, upside down, underwater, on almost any surface including glass and at temperatures ranging from below freezing to over 300C.

When confronted with the same problem, the Russians used a pencil.

This is, by the way, am urban legend. Didn’t happen. If you want to know what did happen you’ll have to read to the end of the post.

Despite that, everybody likes the story. We all like stories that demonstrate the government waste and bureaucratic stupidity. But I brought it for a different reason. When I’ve first heard this story, years back in school, I’ve seen something else in it. Naturally, I didn’t know to much about governments then…

I’ve seen it is something else. That is, our tendency to think about solutions to problems, and not about the problems themselves. My high school math teacher used to say that understanding the solutions is 1/2 the way to the answer. Over the years I learned to appreciate this lesson, although I think he under estimated it. I think understanding the problem is more like 3/4 of the solution.

What is the difference between the two? Imagine the year is 1969. You are a NASA engineer, and your boss came you with a problem: “We found that ball-point pens would not work in zero gravity, can you build me a pen that can write in space?”. What are you going to do? You will go to work to create a pen that can write in zero gravity. And being a brilliant NASA engineer, working with other brilliant engineers, what else can you do? You will come up with a space pen.

The problem is that once your boss changed the problem definition from “how can we keep notes in space” to “how do I get a pen to write in zero gravity” he also, without noticing, changed the problem. He already solved it to say “we will use a pen” and reduced it to a mechanical questions of building this pen. You see, the problem “how can we keep notes in space” can be answered in many different ways, where pen is only one of them. What about a pencil, a laptop (okay, they didn’t have those then, but maybe this is what they needed to develop?), an iPhone, a piece of caulk, using copy paper, and you can come up with another 10 ways if you put your mind to it. Once you reduced the problem to “how do I get a pen to write in zero gravity” we are left with a mechanical question of “how to build a space pen”, which, by the way, engineers like, but might have nothing or little to do with the original problem of taking notes in space. So you end up with a space pen.

In my job I do get customer feedback, and often, it involves suggestions. For me, when I get a suggestion, I always ask what are you are trying to solve and why? Some people take it as an offense. After all, I am the customer, I know what I am talking about, and as the customer, I am always right. I don’t question all of that. What I question is something else. Since most often than not, the “problem” is defined already as a solution, I want to make sure I understand the problem well enough to see if the proposed solution is the right one. In other words, I don’t question the need to take notes in space. I want to verify what is it behind the “how do I get a pen to write in zero gravity” problem. I want to uncover the real problem that needs solving so I end up with the pencil and not the space pen.

So next time when you feel I grill you with those detailed questions that seem to go nowhere and focus around small details, (such as how do you envision this zero gravity pen will be used? when will they use it? Who will use? Does it have to be ink? What will they use it for? Why do you want it…), cut me some slack. It’s not you I question. It is me trying to understand.

Okay, so what is the real space pen story? As I said, the story above is a myth. The space pen is real, in use until today, and does solve some real problems that pencil have.  The space pen was developed by Paul Fisher, the founder of the Fisher pen company, who also created his “bullet pen”  in the 1940’s, which became one of the best-selling pens of the Twentieth Century. Fisher perfected a pen that was sealed with pressure inside of the cartridge that made the ink to flow regardless of gravity. It took him 2 years and $2 million to develop. NASA chose the pen in 1967 for use by Apollo astronauts and it’s been a part of space travel ever since. For the Apollo mission, NASA had purchased 400 pens at $6 each. Prior to 1967, there were no pens that worked in space so there were pencils used. NASA preferred the use of the pen as there were concerned about pencil dust floating around as well as fears that if the tip of a pencil broke off and drifted into the electronics. For the same reasons, the Russians also use the space pen.

To learn about the space pen technology click here. Yes, the space pen is still around. You can even buy on this site a space pen for around $25.

Advertisements

Juts got an email from a customer. It went something like that: ” …., I walked a 70+ year old woman successfully through building her first photo book (over the phone!)… this software is the absolute greatest. And she thinks I’m wonderful, when in fact, it is your software. Thanks, for making me look like a hero!”.

Getting this type of feedback is definitely nice and makes me feel good, okay, really good!. Second to getting this type of feedback, is getting a not-so-pleasant feedback. It might not be pleasant, but it is feedback. At least someone cares enough to tell you what he feels. Not getting any feedback is the worst. That shows no one cares anymore. That hurts.

So, a word about feedback, responses, actions, and timetables.

Lets make one thing clear. We would like to get your feedback!!! We value it and it helps us tremendously. What you like or dislike. Changes and suggestions you would like to see in the software. Suggestions on the process. Anything you feel you want us to know. It can be an email, on the phone, or just stepping into our booth in a trade show. Whatever and whenever you feel like.

We might not always agree with everything (although even boneheaded programmers get the message when they hear it again and again). In fact, we might get conflicting opinions from different people. After all, if we all liked the same things the world would be a really boring place. But I can promise this. We are going to listen. We will digest it and try to fully understand the underlining issue. Sometimes you will suggest a solution, so we will try to understand the problem and see, maybe, just maybe, we can come up with a better (or simpler or faster) solution to the problem. We will balance it all together, add what we have on the table, and see how and when to act.

Its a balancing act of requirements, priorities, resources, risk, and schedules. Doing good work takes time, so results might not show up as fast as you think they should. That does not mean we ignore what you had to say!!! It just that reaching to the peek of the mountain is build out of many small steps, one step at a time, so we keep walking, and walking, one step at a time.

I just finished working on a problem. I might say it feels pretty good to find a real problem that was hiding somewhere and nail it down. The fix was quite simple, not more than 5 minutes work. However, it took me about 6 hours to find what is the problem, or should i say four weeks, 6 hours, and 5 minutes?

It all started, like many other cases, with a customer support email. Some question about something. Emails went back and forth, suggestions were raised, information was requested, and so it went on and on. The problem, you see, is that if the problem this customer had was so obvious, we would see it as well. But we typically don’t! because typically, it is not so obvious.

The problem is that in order to fix we need first to understand, and in order to understand we need to see. And if we can not see it, at least we can see all kind of other information that will gives us clues. So it took us 4 weeks to see it, 6 hours to understand what is going on and when it happens, and once all was in place, 5 minutes to fix it.

So why did it take 4 weeks to see it? Why couldn’t we see it on the first problem report?

This is what we call bug reporting. When you go to the doctor, you try to tell him what is wrong and why did you come to him. You will not say “I feel horrible and I need Xortoplex and I need it now since I have a very important meeting and if you had half a brain you would know what it is and fix me up now”. Well, you’ll be surprised how many bug reports sound this way. Now, don’t get me wrong. I don’t mind the half a brain thing, nor the conclusion that Xortoplex is needed. What I mind is that the problem report has no useful information I can use to start answering the problem. Something like “I have a headache and fever. I vomited twice since breakfast and my teeth are falling.”. Now, if after that you would like to add that last time Xortoplex worked wonders that is fine, but that can not come instead of a report of the problem.

So, how can we report a problem in a way we can reposed effectively and solve it? This is a great article that will better explain what are we looking for in a report and why.

To sum it up, here are a few rules of thumb for effective reporting.

* Keep in mind that we are on the same side! We want to help. We want to solve the problem. Since we do not sit in your office and did not see the problem, we need your help. The more information we get, the faster we can understand what the issue is, the faster we can respond.

* The best outcome of the report is to have the programmer see the failure with their own eyes. Since they can’t be with you when that happens, give them detailed instructions so that they can make it fail for themselves. If you can attach screen shots, please do. If you have files used or generated, such as images, PDF files, log files, please send them.

* In case the programmer can’t see it failing themselves, he needs to understand what went wrong. Describe everything in detail. State what you saw, and also state what you expected to see. Write down error messages, if they were. Like above, files used in the process, like image files, PDF files and log files ate worth their weight in gold.

* By all means try to diagnose the fault yourself, but even if you do, you should still report the symptoms.

* Be ready to provide extra information if the programmer needs it. If they didn’t need it, they wouldn’t be asking for it. They aren’t being deliberately awkward. Any information on your system will help, OS, version, memory, hard drive, images used….. Better, just send this information in the first place. Be aware that small details you don’t see as important might be very important.

* Write clearly. Say what you mean, and make sure it can’t be misinterpreted. “It crashed” might be interpreted in many ways, and so does “it didn’t work”. One liners are great for punch lines, but are pretty useless for problem diagnostics. Don’t worry. You can not over explain.

Anyway, if you missed it above, it is well written and easy reading.

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

Latest pictures form Print China. Note the logo on the center stage.

China1

DSC0465