I rarely forecast doom for a company. However if my recent experience with HP is any example, the company is doomed. I was looking for 2 laptops to be used in my web mail station project (anyone wanting information on that project should look at Thalasar Ventures I will post updates there). As these are going in a web mail station, they are certainly going to be beat to death. So I considered Dell (the old standby). They were offering a great deal on the 1200s. But I got suckered by the great ads HP is now running. When I added in the price of wireless and support, HP turned out on top at least in price. HP has always stood out in my mind as a high quality provider. So away I went to HP TV. After placing my order, I wondered why I didn't recieve an email confirmation of the order. So I quickly called HP to find out. After speaking with a customer service representative, it became apparent that when I input my email address for confirmation and login, I typed .con instead of .com. The customer service rep of course said it was my fault for making a typo. I then thought back to my team's own software development work in open source ecommerce in 1995/1996. Email address verification (that the email address added followed the form of a valid email address) was added in our SECOND alpha release in 1996. Later we added functionality which checked that the email address actually routed and was deliverable. HP doesn't have the first basic functionality nine years later. They don't bother to check to see if an email address is valid with the order!
The funny thing is this email login is how you are identified as a customer at HP. So when I requested they change it (ie correct it so I can actually communicate with them, I was told this was impossible. Why is email address verification such an impossibility for HP? Could Broadvision (there ecommerce software provider recently taken private) be so inflexible? Is their It infrastructure so brittle?
It doesn't bode well for a company. I had a similar problem at Dell. They were able to quickly consolidate accounts under a single login. If HP's IT infrastructure is so brittle how can they expect to compete?
What struck me as even stranger is that the HP rep didn't think it strange that their ecommerce application doesn't validate email addresses and thus account signons. I guess Carly really did kill the culture of innovation at HP.
Monday, August 08, 2005
Monday, August 01, 2005
Art of The Demo.
One of the projects I had introduced to the guys at Highlands University was nearing completion. Anthony the project lead called me into their office to go over the project and make sure we hit it with the work order. So with work order in hand we started. Unfourtunately the programmer had been working on the site that day so it kept breaking. I recoginized the error was a simple one and told them I wasn't in rush for the project and I could come back tomorrow. I also realized that me sitting there put enough pressure on the programmer so he was unlikely to find the error. Just better to come back when he had time to find the missing bracket (which indeed was the error). So the next day I returned and with work order in hand we go through the site. I thought about the demonstration I saw, which was pretty straightforward, and how many times I had to give a similar demonstration for clients when we completed a project. So I though perhaps I could distill some rough guidelines for a demonstration. Now most of my demonstrations were done for a web site but with a little imagination you can expand them to include product demonstrations as well. Here's Brian's Rough rules for demonstration.
1. Control the demonstration. This means that you shouldn't allow the client to side track the demonstration with questions. This means simply saying,"That's a great question. I would like to handle questions when we get to the end." Make sure though that you write down the clients' question or note it. I suggest writing it down as your mind will be focused on the demonstration. Keeping a question notepad is one way to do it. It is also useful for writing down short notes when the application doesn't quite work as expected. Also don't let the customers randomly monkey around with either the equipment or the site. If you want the customer to try a feature, show the customer the feature you want to demonstrate, show them how to do it and then let them do jsut that feature. It's a product ask for it back so that you "may continue the demonstration".
2. Know your click path. For this latest demonstration we used the work order to drive the feature demonstration. This can sometimes cause problems as certain features are related to each other. It's often more natural to demonstrate certain capabilities when they are clustered together. Find out what will naturally go together when you practice the demonstration. If you are not the developer, then have a developer in the room when you do your first practice session. Some of this advice will actually be helpful as they point out how features may be clustered together.
3. Declare the system "Gold." This is a hard one for developers to resist. Quite often they think they can stuff a feature or finish in time for the demonstration. If developers are working on features before the demonstration you can expect that demonstration to go poorly. If all the promised features are not in this demonstration, let the customer know early so as to minimize the expectations.At some point declare that all work must stop so that you can prepare for the demonstration.
4. Set the expectations. This is an important part of any demonstration. As a demonstration can happen at any point in the development process especially in the XP, you should set the expectation on what the customer is going to see. If demonstrating a specific module, state it at the beginning of the demonstration, "This demonstration will only be covering the customer profile and profile management features." Customers are always going to want to see more so remember point #1.
5. Practice the demosntration. A demonstration is a form of public speaking and you would never think of giving a speech without practicing it once. By practicing the demonstration in front a single person (preferably a developer familar with it) you will certainly feel more comfortable with the system.
6. Developers often do not make the best demonstrators. Why? Because they are extremely familar with the internals of the system they are demonstrating. So they may make leaps or even be tempted to make changes during the demonstration. Remember point #3. No more features.
7. The missing feature. Sometimes you just don't have everything you need for this demonstration. If you forget to mention this during the expectation setting phase of the demonstration, you might be able to get away with dreaded,"In the final version of the system, feature X will happen this way. I am sorry we weren't able to get ready for this demonstration." Of course that feature might not be in the work order, but you can bet the customer will certainly want it. At the final demonstration, the customer will certainly the feature as you mentioned it rather than how the contract reads.
That's all for now. I will update this from time to time. It will be nice to re-visit it now and again.
1. Control the demonstration. This means that you shouldn't allow the client to side track the demonstration with questions. This means simply saying,"That's a great question. I would like to handle questions when we get to the end." Make sure though that you write down the clients' question or note it. I suggest writing it down as your mind will be focused on the demonstration. Keeping a question notepad is one way to do it. It is also useful for writing down short notes when the application doesn't quite work as expected. Also don't let the customers randomly monkey around with either the equipment or the site. If you want the customer to try a feature, show the customer the feature you want to demonstrate, show them how to do it and then let them do jsut that feature. It's a product ask for it back so that you "may continue the demonstration".
2. Know your click path. For this latest demonstration we used the work order to drive the feature demonstration. This can sometimes cause problems as certain features are related to each other. It's often more natural to demonstrate certain capabilities when they are clustered together. Find out what will naturally go together when you practice the demonstration. If you are not the developer, then have a developer in the room when you do your first practice session. Some of this advice will actually be helpful as they point out how features may be clustered together.
3. Declare the system "Gold." This is a hard one for developers to resist. Quite often they think they can stuff a feature or finish in time for the demonstration. If developers are working on features before the demonstration you can expect that demonstration to go poorly. If all the promised features are not in this demonstration, let the customer know early so as to minimize the expectations.At some point declare that all work must stop so that you can prepare for the demonstration.
4. Set the expectations. This is an important part of any demonstration. As a demonstration can happen at any point in the development process especially in the XP, you should set the expectation on what the customer is going to see. If demonstrating a specific module, state it at the beginning of the demonstration, "This demonstration will only be covering the customer profile and profile management features." Customers are always going to want to see more so remember point #1.
5. Practice the demosntration. A demonstration is a form of public speaking and you would never think of giving a speech without practicing it once. By practicing the demonstration in front a single person (preferably a developer familar with it) you will certainly feel more comfortable with the system.
6. Developers often do not make the best demonstrators. Why? Because they are extremely familar with the internals of the system they are demonstrating. So they may make leaps or even be tempted to make changes during the demonstration. Remember point #3. No more features.
7. The missing feature. Sometimes you just don't have everything you need for this demonstration. If you forget to mention this during the expectation setting phase of the demonstration, you might be able to get away with dreaded,"In the final version of the system, feature X will happen this way. I am sorry we weren't able to get ready for this demonstration." Of course that feature might not be in the work order, but you can bet the customer will certainly want it. At the final demonstration, the customer will certainly the feature as you mentioned it rather than how the contract reads.
That's all for now. I will update this from time to time. It will be nice to re-visit it now and again.
Tuesday, July 26, 2005
How not to introduce open source
A recent article on Slashdot covered the topic of how to discuss open source software within the context of the a business. As most of these discussion often do, it focused on the "openness" or availability of the source code as the primary introduction point. I think at this point in the development of open source software, focusing a discussion on the availability of the source code is a waste of time. For small businesses an esoteric discussion over which open source license (GPL vs FreeBSD) is a confusing waste of time. Discuss how this meets the business needs, not the availability of the source code.
Friday, July 22, 2005
MS FUD Misses Mark Again.
Recently Martin Taylor the General Manager of platform strategy at Microsoft, was given the oppurtunity to show complete lack understanding of both the power of the LAMP platform and the power of Linux. This is yet another attempt to take some shine off the Linux apple. I usually love reading these interviews with MS as it shows how much they are missing in regard to LAMP. What's very interesting about these recent pieces here and here is what they indicate about the mind-set of Microsoft and ultimately how they just don't get it.
First off let's dissect the FUD coming from this MS talking head.
"The Linux phenomenon created this emotional hype or spike where, in some ways, people became less concerned about some of these practical issues around cost of ownership, reliability, security and so on,"
Incredible. One of the most insecure operating systems on the planet in active use is Microsoft Windows. Given the huge associated costs with Windows (viruses, spyware, and brittle development) how does anyone with a straight face claim to be the more reliable platform. The simple fact of the matter running Windows in a lab where it cannot be attacked doesn't measure the entire cost of ownership of Windows. Viruses and spyware alone make Windows not worth it.
"They're also realizing they can't migrate and evolve (open-source technology) as much as they had thought. For example, U.S. company Flyi.com handles about 90 percent of travel reservations through their online portal, which they run on Linux and Apache.
The systems were running fine until the company had a huge spike in traffic, and there were all kinds of downtime issues. So they did the upgrades, added a few servers, some hardware, some memory and new technologies around the Web site to do more customer relationship database tracking. It was all very complex, and some of the seams of the Linux architecture were beginning to show. "
Poor design decisions can happen on any platform. Not properly architected a large scale web site and the seams will show in any architecture. I did a little digging on his noted example company Flyi.com Independence Air is now a small low cost airline. The Google Page Rank of their home page is a 7 which while respectatable, is not earth shattering. Their customer story from MS is located here. In that study it's apparent that Independence Air was sold a bill of goods in development of their new system based on Linux. Their first step was to buy a BEA Application server for $75,000. They then hired 5 consultants at 150/hour for six months to customize what should have been a relatively simply project. In this particular case the real weakness of the project wasn't Linux but the Bea Application Server which caused costs to spiral out of control. That combined with grossly incompetent consultants really created the problem. Starting off with a $75,000 closed source application server is not the way to begin a project. I find it interesting that in the customer testimonial, the CIO blamed the consultants instead of his own poor decision making in the process deploying the system.
One quote I find interesting,
"Most IT professionals don't want to be in the business of maintaining system-level software,"
That's true. However businesses that are being built on the LAMP stack use their control of the system at the system level as an economic advantage. Take a look at Google. System level control of the operating system enables them to scale search in a way that has never been done before. This gives them a platform from which to launch new web products that can quickly scale up without the time-consuming
Here's the true telling quote.
"From a competitive standpoint, take Linux, for example. There's really nothing innovative today that Linux does that we can't do. There's no new feature or new design that can be done only on Linux, and not on Microsoft."
The problem is that statement can be turned around. "There's nothing really innovative today that Microsoft does that Linux cannot do." Therein lies the rub for Microsoft. Since the LAMP stack commoditizes large chunks of the software stack, it enables a small set of developers launch projects with relatively little work on the basic stack elements.
First off let's dissect the FUD coming from this MS talking head.
"The Linux phenomenon created this emotional hype or spike where, in some ways, people became less concerned about some of these practical issues around cost of ownership, reliability, security and so on,"
Incredible. One of the most insecure operating systems on the planet in active use is Microsoft Windows. Given the huge associated costs with Windows (viruses, spyware, and brittle development) how does anyone with a straight face claim to be the more reliable platform. The simple fact of the matter running Windows in a lab where it cannot be attacked doesn't measure the entire cost of ownership of Windows. Viruses and spyware alone make Windows not worth it.
"They're also realizing they can't migrate and evolve (open-source technology) as much as they had thought. For example, U.S. company Flyi.com handles about 90 percent of travel reservations through their online portal, which they run on Linux and Apache.
The systems were running fine until the company had a huge spike in traffic, and there were all kinds of downtime issues. So they did the upgrades, added a few servers, some hardware, some memory and new technologies around the Web site to do more customer relationship database tracking. It was all very complex, and some of the seams of the Linux architecture were beginning to show. "
Poor design decisions can happen on any platform. Not properly architected a large scale web site and the seams will show in any architecture. I did a little digging on his noted example company Flyi.com Independence Air is now a small low cost airline. The Google Page Rank of their home page is a 7 which while respectatable, is not earth shattering. Their customer story from MS is located here. In that study it's apparent that Independence Air was sold a bill of goods in development of their new system based on Linux. Their first step was to buy a BEA Application server for $75,000. They then hired 5 consultants at 150/hour for six months to customize what should have been a relatively simply project. In this particular case the real weakness of the project wasn't Linux but the Bea Application Server which caused costs to spiral out of control. That combined with grossly incompetent consultants really created the problem. Starting off with a $75,000 closed source application server is not the way to begin a project. I find it interesting that in the customer testimonial, the CIO blamed the consultants instead of his own poor decision making in the process deploying the system.
One quote I find interesting,
"Most IT professionals don't want to be in the business of maintaining system-level software,"
That's true. However businesses that are being built on the LAMP stack use their control of the system at the system level as an economic advantage. Take a look at Google. System level control of the operating system enables them to scale search in a way that has never been done before. This gives them a platform from which to launch new web products that can quickly scale up without the time-consuming
Here's the true telling quote.
"From a competitive standpoint, take Linux, for example. There's really nothing innovative today that Linux does that we can't do. There's no new feature or new design that can be done only on Linux, and not on Microsoft."
The problem is that statement can be turned around. "There's nothing really innovative today that Microsoft does that Linux cannot do." Therein lies the rub for Microsoft. Since the LAMP stack commoditizes large chunks of the software stack, it enables a small set of developers launch projects with relatively little work on the basic stack elements.
Sunday, July 17, 2005
Save the Highlands University Software Development Program
I recently started working with the local university which has a software development program. Alas the new president is terminating the program which is somewhat unique. While students are taking traditional Comp Sci courses, they are also doing software development through a mentoring relationship. I find this to be a great idea as software development often benefits from a mentor. Additionally they use a variant on the XP Methodology which is really quite useful.
This sort of mentoring approach to software development lends itself well to teaching and more importantly to producing quality software engineers. Unfortunately the current administration of New Mexico Highlands University feels that the program is either too edgy or not like other programs in the area to warrant continuing it. So they have canceled the program. So like Sisyphus I am going to start an effort to save the program.
First off contact New Mexico Highlands University. Since the University is small, let's contact the Office of the President
For those of you averse to clicking - here's the information. Please note all phone are in the 505 area code and Manny Aragon is the current president of Highlands University
Manny M. Aragon
President's Office
President
Phone: 454-3269
Room: RAB-101
Laura LaCour-Johnson
President's Office
Senior Admin. Asst to the President
Phone: 454-3269
Room: RAB-101
Yvonne M. Quintana
President's Office
Senior Executive Administrative Assistant
Phone: 454-3229
Room: RAB-101
Geez this guy has too assistants? Highlands is a university with 5,000 students. That's one too many assistants.
This sort of mentoring approach to software development lends itself well to teaching and more importantly to producing quality software engineers. Unfortunately the current administration of New Mexico Highlands University feels that the program is either too edgy or not like other programs in the area to warrant continuing it. So they have canceled the program. So like Sisyphus I am going to start an effort to save the program.
First off contact New Mexico Highlands University. Since the University is small, let's contact the Office of the President
For those of you averse to clicking - here's the information. Please note all phone are in the 505 area code and Manny Aragon is the current president of Highlands University
Manny M. Aragon
President's Office
President
Phone: 454-3269
Room: RAB-101
Laura LaCour-Johnson
President's Office
Senior Admin. Asst to the President
Phone: 454-3269
Room: RAB-101
Yvonne M. Quintana
President's Office
Senior Executive Administrative Assistant
Phone: 454-3229
Room: RAB-101
Geez this guy has too assistants? Highlands is a university with 5,000 students. That's one too many assistants.
Thursday, July 14, 2005
Open Source Growing Pains
Drupal.org recently had a three day outage. Drupal is a CMS (Content Management System) written in PHP and supported by a MySQL back-end and which with I have just completed a small pilot project. These reflects the relative growing pains with Drupal as young open source project. I say young but Drupal is WILDLY popular. It's popular for several reasons. First it's written in PHP, one of the new young languages that is relatively easy to learn. Secondly it's actually a relatively secure package. Thirdly it pretty damn useful. It's literally community in a box and that's pretty cool.
So I contributed to the project about 80 EUs to help buy the new cluster of servers this project needed. They had long out grown their shared hosting environment but it took a crisis to make the change. They raised over $10,000 for equipment in less than 48 hours. This tells you how popular this project is. So I am encouraging everyone to give Drupal a try. If you like it, support Drupal with a donation.
So I contributed to the project about 80 EUs to help buy the new cluster of servers this project needed. They had long out grown their shared hosting environment but it took a crisis to make the change. They raised over $10,000 for equipment in less than 48 hours. This tells you how popular this project is. So I am encouraging everyone to give Drupal a try. If you like it, support Drupal with a donation.
Subscribe to:
Posts (Atom)