A Complaint is a Gift

One of the great faults of software groups is that we assume if we don't hear from our customers, they are happy. This is a lie from hell.

How happy are you with Windows? Have you ever called Bill Gates? I rest my case.

We need to strive to improve feedback with our software customers. I uninstalled Skype from my work machine today (something about corporate policy and security). I was pleasantly surprised to see in my firefox browser a page from Skype entitled, "We're really sorry to see you go. Did you have problems? We can help." This shows a great attitude that Skype really cares about its customers and improving their product.
A complaint really is a gift, and we need to accept these gifts graciously and learn from them.
One of the new things in our application I put in this release is a link to a wiki for suggestions and feedback. Now instead of steaming that a page didn't remember previous settings a user can go to the wiki and document their needs while fresh in their mind. It's an easy thing to do and a great way to get feedback, although actually talking with your customers is the best idea.

Creating Favicons Online

I recently found a wonderful site for creating favicons, you know, those cute itsy-bitsy images that appear to the left of your tab uhm, you are using tabs?.
It's www.favicon.cc. I uploaded a graphic like this one to the site and it converted it to a tiny little favicon. Check it out at http://www.MayanPeriodic.com.

Butterflies and Stored Procedures

The Monarch caterpillar eats the poisonous milkweed plant so as an adult the butterfly is quite toxic to birds. A young bird will eat the butterfly and be so repulsed by the taste will not try to eat another in its lifetime. Some other species of butterflys mimic the color of the Monarch even though they are not poisonous, but quite tasty to birds. But a young bird after tasting the dreadful Monarch will not eat its counterfeit.
I'm like that with stored procedures. In one of my early projects stored procedures left a bad taste in my mouth. Stored procedures were cumbersome to code, difficult to synchronize across multiple databases and they always seemed to be out of sync with version control. Looking back all those issues could have be averted with better build management, but stored procedures left a bad taste in my mouth.
Today, one of my programmers came up with a good case for a stored procedure. He is working on one program that interfaces with a database, but many other programs are constantly changing the database. Currently they all issue a series of sql commands to affect a change in the database, but if one of the programs fails to get all the sql commands for a change correct, the database will be in an unsteady state.
Better to use a stored procedure to ensure consistency across the applications.
Maybe that first butterfly was a fluke.