E-mail

I just wanted to repost the following amusing excerpt from Larry Bailin’s book, Mommy, Where Do Customers Come From?

How about email? I am going to go out on a limb here and say that if you are not using email at this point in time, the rest of us are just waiting for you to die. Anyone that is not using email, especially in their business, will soon just vanish. We won’t be able to hear you or communicate with you. You will eventually just cease to be. So, get with the program or move over and let your competition communicate with us in the way we want… the way we demand to be communicated with. Get it? Got it? Good–now go get a friggin’ email account.

When new computers fail

Here’s another quote from the article that I cited earlier.

The world is starting to notice that computers are cranky, complicated and decidedly user-unfriendly. In fact, so many people complain about these piles of silicon, wire, metal and glass that computer vendors are now ranked No. 7 on the Better Business Bureau’s nationwide complaint list, just behind used-car dealerships and home remodeling contractors. Even brand-new computers fail at an alarming rate. More than half of the respondents to a recent ComputerWorld magazine survey found serious flaws with their new machines, right out of the box.

Once, years ago, I was using this tiny little handheld computer. Not a Palm Pilot or PocketPC, mind you. Rather, it was basically a compact controller. At one point, the device would no longer communicate with my host computer, and I felt confident that it was a malfunction. I was also fairly certain (though not 100% certain) that I had not done anything to damage the thing. (It’s difficult to damage a serial port simply by wiring it incorrectly.)

However, one other fella said, “I dont think so. It’s a new computer, after all. Back when I did tech support for another company, we’d routinely get parts shipped back to us that had no malfunctions whatsoever. That happened about 90% of the time.” (I’m obviously paraphrasing here, as I don’t remember the details of what he said. That was the gist of it.)

Now, he could have been right. As I said, I can’t rule out the possibility that I somehow messed the thing up. However, even if 90% of all customer-reported malfunctions are bogus, this does not logically mean that a brand new computer cannot fail. In fact, as the article I cited says, they do fail at an alarming rate.

Common wisdom says that if a computer fails, it will probably do so within the first few weeks of purchase. That’s precisely why manufacturers typically provide one-year warranties.

Some managers might not be so understanding. After all, if a new computer breaks down, surely that means you’ve mishandled it, right? And given the stress that managers are often under, I can understand why they might feel that way. However, the reality is that new electronic devices — especially things as complex as computers — routinely do break down early on, even when the user is not at fault. It could indeed be user error, but it could also quite likely be a genuine hardware problem. Such problems are common indeed.

I hate bloatware

I hate bloatware. I hate software that is so hopelessly bloated with features of questionable value that it no longer performs in a quick, timely manner. (Yeah, Windows Vista. I’m looking at you!)

This article offered some useful insights into this issue. To wit:

The brutal realities of the software marketplace are probably more responsible for our frustration than the industry’s growing pains. Unlike cars and other consumer products, software doesn’t wear out. Sell people a functional word processing package today, and they can use it for the rest of their lives. So, to continue making money, software vendors are caught in a never-ending quest to add features and functions they hope will entice consumers to buy upgrades.

As a result, today’s fully loaded applications are more complicated, require more electronic memory and are more likely to crash than their forebears. For example, the first version of Microsoft Word, released in 1984, used a mere 27,000 lines of code. Today’s version has 100 times as many lines and three times as many commands. Included are capabilities that not long ago could have passed for distinct applications in their own right: a drawing program, a desktop publishing program and a web page authoring program.

To some extent, I’m sympathetic. Nevertheless, it’s a huge annoyance.

The article goes on to say,

Philippe Kahn, a software executive who helped developed the Micral, one of the first personal computers in the 1970s, calls it “bloatware.” Fierce competition accelerates this virtual obesity. When one vendor adds 10 more features, its competitors are forced to follow suit or lose market share.

Consumer experts insist buyers want bigger, better hardware and software. Just like fast cars and designer clothes, the latest computer gadget makes buyers feel powerful and cool, says Terry Winograd, a Stanford computer science professor who heads the program in human-computer interaction. “Most of it has to do with self-image and status.”

When it comes to software, less is definitely not more, as Microsoft found out when it tried to sell a version of the spreadsheet program Excel with shorter, simpler menus. Nobody wanted to buy it, says Ken Dye, who manages the company’s desktop products test labs. “People want the features because they say to themselves, ‘One day I may use them.’ Just like they prefer to buy a whole shed full of tools rather than the one wrench they need today.”

The pressure to rush sexy new products to market is so great, in fact, that quality assurance often falls by the wayside, according to a survey of product managers in 11 software companies that was released last year by the Stanford Computer Industry Project.

A majority of the companies surveyed allowed engineers to add and remove features right up to the product release date–even if that meant that the manuals were no longer accurate. Squeezed by their own marketing departments, product managers poured out their frustration over slipshod quality control in post-survey interviews. “It almost brought some of them to tears,” recalls Barr, who managed the study.

Yep, based on my experience with previous companies, I can really believe that quality control falls by the wayside. The article also raised a good point about how documentation invariably suffers. (This article here discusses that matter as well.)

Robot grippers

I once saw these grippers that some poor, misguided soul had designed for a chess-playing robot. The grippers would grasp onto the chesspieces using these locating pins that had to be precisely aligned to within half a millimeter or so. The result? If the chesspieces got nudged by even the slightest bit, or if they were not set down with the greatest of precision (thereby causing them to rock), the grippers would not work.

This designer could have learned a thing or two about pose-intolerant fixture design.

Flow Cytometry

Flow cytometry is a method for optically enumerating components or structural features of cells. In effect, it is used for counting the number of cells within a fluid stream that contain a particular feature. Thousands of cells can be counted in just a few seconds.

Found a very nifty tutorial on flow cytometry here. Very impressive indeed.

Flow cytometers are frequently used for performing complete blood cell counts in clinical laboratories without using fluorescence. More versatile instruments use fluorescence, giving them more flexibilty when it comes to distinguishing cell types.

Flow cytometry when dealing with cellular responses in high frequencies. For low-frequency responses, the ELISPOT method is more sensitive. These two techniques can therefore complement each other in terms of sensitivity and effectiveness.

Impressions on XP

Some programmers really love eXtreme Programming; however, I think that the following posts that I found on LinkedIn summarize my views reasonably well.

My previous post went down the drain and I have not the time to write it all over again.

Overall the concept seems good but my experience with the companies I worked for that claimed happily “we do extreme programming” was that it was an excuse for not producing much design or documentation. A programmer goes straight into coding, a good software developer analyses the problem, produces a design and at least some documentation before digging into coding.

As someone pointed, its success also relies on support from management and the team itself. A team is only as good as its weakest link. And sadly sometimes management has not the slightest idea of software development.

My initial thoughts about Extreme Programming (XP) were (and still are) that some of the steps are great ideas, and some of them are excessive. In general, it is full of good ideas, but its something that will definitely not fit everyone or every work environment. I tend to think people will use XP like they use a buffet — take what they like and leave the rest behind.

Overall the concept seems good but my experience with the companies I worked for that claimed happily “we do extreme programming” was that it was an excuse for not producing much design or documentation. A programmer goes straight into coding, a good software developer analyses the problem, produces a design and at least some documentation before digging into coding.

As someone pointed, its success also relies on support from management and the team itself. A team is only as good as its weakest link. And sadly sometimes management has not the slightest idea of software development.

Memristors

Been reading about these memristors from HP.  Pretty neat technology, and if they can make it work on a large scale, that’ll be quite an accomplishment indeed.

I think I’ll hold off on buying any HP stock for a while, though. That’d be foolish.

Agile software development

Much has been said about agile software development techniques. Personally, I think that these techniques are overhyped.  I’m not saying that there’s no validity to them, but it does appear to me that it’s generally best to put a greater degree of forethought into one’s designs.  In other words, don’t skip (or scrimp on) the initial software design.  The design doesn’t have to be highly detailed, but a measure of upfront design is still important–even if it’s never actually committed to paper.

Additionally, proponents of agile design don’t always realize that software success is not limited to shipping on time and meeting the requirements.  It’s also a matter of coming up with a design that’s maintainable and that is internally robust.  This is not always evident when one uses “agile” testing and design methodologies.