I've been refinishing my kitchen cabinets and I need to replace the hinges with a new style. Face Frame No-Mortise concealed hinges which are apparently very difficult to locate. During my search I found that a lot of cabinet hinge ecommerce stores had terrible category structures.

Almost every store divided products by brand. Who cares what brand my cabinet hinges are? I guess maybe some high end hinges are desirable but I'm looking for function not brand. Brand is how the owner's of the web sites think about hinges because they have to purchase them from manufacturers and know which hinges are most profitable and where they come from. As a shopper of hinges I need to find the ones that will work.

Think about how your customers will be looking for products. If the cabinet stores had created categories for types of hinges it would be easy to locate what I wanted to buy. In fact, the store where I did end up purchasing was the one that did have categories by functionality.

Do your categories match up with how customers actually look for your products or do they line up with how you think about your products? Call up some customers and find out.

Last night I watched professional musicians deal with unexpected failure in front of a crowd of thousands. If your store fails can you handle it as well as they did?

 A friend invited me to go to the local Rock the Vote concert which sounded like fun. It was unusually cold for October and waiting in line for the super extensive metal detector sweep would have been uncomfortable except for the in-line entertainment. The girl in front of us was teetering from side to side, flirting with everyone who wasn't her boyfriend and generally serving as a lesson on why you don't ever want to drink beyond your limits. Surprisingly the metal detector guy could care less about how drunk she was as long as she wasn't hiding a 9mm in her coat.

The show was a collection of short performances by Nora Jones, Jack Johnson, Sheryl Crow and the Beastie Boys. Each performer came out for a short set and then played a few songs together. It was the ensemble performances that had unexpected failures.

 One minute into a Johnny Cash song the microphone started to crackle and pop for Nora Jone's Banjo player. You couldn't miss it from the audience but I was interested to see how everyone on stage handled it. 

First, while I know that everyone on stage noticed, there was nothing more than a short glance without a single blip in the other performances.

Second, a roadie was on stage in 2 seconds flat and looking over the connections.

Third, while the roadie was working everyone else carried on with the show.

Fourth, when the roadie couldn't determine the cause quickly the banjo player grabbed her backup guitar and joined in as though she had meant to be playing the guitar all along.

If one part of your operations fail do the other parts continue on without it? If your ship manager calls in sick during your busiest week who takes over? Can you operate without that person?

When something fails do you have a "roadie" waiting just off stage to immediately review the problem? Does your hosting company have 24 hours support? If the problem is a software issue who's on call and guaranteed to be available?

If your "roadie" can't fix the problem on the fly do you have a backup system in place? What happens if UPS goes offline? How do you determine shipping prices? 

Have you tested your backup plans when you don't need them? My hosting company routinely "pulls the plug" on outside power to verify that the backup power supply is working as expected? Test your backup plans before you need them.

Google released their own web browser today, Google Chrome. Right now it's only available for Windows XP and Vista but I'm sure it will be cross platform soon. It's based on WebKit which is the same rendering engine that Apple uses for Safari. This is a good things for web developers as we won't have to support another new rendering engine. WebKit is open source and very standards compliant.

One major difference is Google's focus on simplicity. Taking a page out of Apple's playbook they've decided to strip away everything that isn't needed and deliver a rocket fast simple browser. They wrote their own Javascript engine that is supposed to be significantly faster and I suspect they've learned a lot from Gmail and other Google apps.

The clear business strategy is to deliver an application platform for the web. If they have a web browser that compiles javascript to native code for execution they've basically created the .Google Framework for Windows. The Microsoft .Net Framework compiles C# to an intermediate language which is then compiled to native code. Now Google can use their toolsets like GWT to compile dynamically to native code on a windows host. Imagine GMail running as fast as your native mail client. The last part that's needed is offline access. Google Gears provides that feature already.

 So, Google just delivered the tools to send a web application directly to your desktop running at near native speed. You don't need to learn Silverlight, Flash or Adobe Air. Just HTML and javascript.

The platform wars are moving beyond Windows vs. Mac vs. Linux to Silverlight Runtime vs. Adobe Air vs. Google Chrome 

When processing credit card transactions a credit card number, the customer's name, address and the amount to process are sent to the issuing bank. Over the past few years credit card companies have added extra numbers to their cards for security called "security codes" or "CVV codes." The CVV code is different on every card issued even if the account number is the same. Because of the new code, banks are requesting that information is sent with transactions.

The bank sends a response message with a generic Sucess/Failure and then some more detailed information. Two of those additional fields are the Address Verification (AVS) response and CVV response. This tells the requesting program if the address matches the one on file (and how closely) and if the CVV code was correct.

However, the current processing standard does not decline transactions if the address and CVV code aren't correct. The responses are only information for the requesting application. Some credit card gateways like Authorize.net can automatically send a Failure response to applications based on CVV settings but the transaction at the bank is not automatically cancelled. Smart gateways will send a "VOID" transaction to cancel any charges if they are failing on CVV codes but not all do. Also, the gateway may not be able to cancel authorizations/holds on the card. This can cause trouble when a customer tries several times to process a card that fails. They may end up with duplicate holds on their account even though no actual charges have been made. Very confusing!

Last summer BV Software took on a large custom programming job for a social networking site targeting baby boomers. It was a great opportunity to expand our consulting services with a 6 month long project. Long term contracts are a great way to keep programmers busy and expand our team. The project didn't turn out as planned...

I've been in the software business long enough to know that you can promise hours or you can promise functionality when creating custom programs. If you promise functionality without limit on hours you have to be absolutely sure that you can deliver the project in less time than the cost of your resources will eat up. This turns out to be a difficult problem. Steve McConnell (no relation to me) has a great book on Software estimation and the challenges involved. Most clients are not willing to pay up front for the hours required to fully document and understand a problem before any coding begins. If you don't fully understand the problem you're trying to solve it is impossible to put a fixed cost number on it.

So that leaves contracts that sell hours of time. This particular long term contract promised 400 hours of time over a six month period. We estimated how long several tasks would take and gave the client an idea of what we thought those hours would cover. 

This client was fairly high profile and we worked like dogs to help them meet their launch deadlines. However, like most projects, the requirements were constantly changing. We got request to change tax and shipping algorithms for or five times. We got requests to manually go into the database and change the pricing of one or two Harry Potter books! We were sent several conflicting designs and layouts that all had to be integrated "today or else!" There were last minute additions of flash product carousels and finally, the biggest change request of all: "Our site needs to be as fast as Amazon.com with all the same features and 5 million products. You have four weeks." The client expected to accomlish all of this for less than $50,000 working nights and weekends on an unrealistic deadline.

Needless to say we burned through the 400 hours pretty quickly. That's were the real problem began.

The client had known all along the hours were ticking away. We sent detailed status updates and let them know that we needed to extend the agreement or we had to stop working. We delivered the site, working as originally expected on time in the 400 hours budgeted. The client had paid their bills while we were working but as soon as the code was delivered all payments stopped.

I had made a huge mistake because I allowed our team to work through the 400 hours in about 2 months time. The client had paid for two months but still owed for the remaining 4. With the code in their hands and no more hours to use they simply felt entitled to stop paying us.

Fortunately, I was experienced enough to insist on a contract of hours over features. That means the client is in breach of contract no matter what was delivered if they don't pay. We'll see how everything turns out now that it's going to litigation. I fully expect to collect what's due including court costs and punitive damages but it's not a process I wanted to deal with. 

Even with all the frustration there is something valuable to gain. It was a mistake to offer so much credit to a client. It was a mistake to work an unrealistic schedule just to please a client. It was a mistake to deliver source code with so much of a contract not paid off. I know that the knowledge from this experience will help with our future consulting jobs just like selling hours instead of features helped with this one.