Chrome OS, the user experience, storage, and software prices

This week started with a bang when Google announced they would create an OS-like version of Chrome designed to displace the traditional OS and initially targeted at netbooks. Given the coverage in the press, the world seems to have a short memory. You couldn't swing a dead cat back in the mid 1990's without hitting a similar strategy--specifically from Sun. Granted, the implementation is different here. Sun wanted to use the Java VM on the hardware and run a web browser on top of it, whereas Google wants to run the web browser on the hardware, and rely on apps on top of that. But the limitations and criteria for success are the same. They will need to convince users that everything they need is on the web. This simply wasn't possible in 1996. Will it be possible now?

This is a nice piece about how new and profitable user experiences can be created from existing technologies. I'm interested in other examples of this. One that pops to mind might be the story of the Ford Mustang.

There are some amazing things happening in storage right now. Prices continue to plummet while simultaneously offering more sophisticated technology. Granted, this is a general trend for any technology sector, but seems to be most disruptive to storage today.

I can't read this piece about intellectual property being free without thinking of software prices. If one could measure software complexity in quantifiable terms (like we do transistors on a processor), the complexity increase in software vs cost would put Moore's Law to shame. There is nothing tangible to prop up prices for any intellectual property (including software). Prices will always fall--deal with it. You only have three choices to sustain growth in a software business: high volume, very low prices (think Apple iPhone apps or MS Office), own a platform (sometimes a prerequisite for choice number 1--think Apple and Microsoft), or bundle software with other high margin offerings (like services--think Oracle or IBM). This natural progression of software prices to near zero is going to be extremely disruptive to the video surveillance industry in the near future.

Transformations and team

Seth Godin's Learning from Singer is a nice, in-your-face reminder to reinvent yourself or die. The IT space is littered with the bodies of companies that couldn't do it (like DEC), and some surprisingly that could, like IBM. I'm particularly fond of the IBM example, as I think it's one of the miraculous cultural transformation stories in IT.

Speaking of transformation, two examples of how our (video security) industry is transforming. Milestone's release of a generic IP camera driver and the announcement that LILIN will release an ONVIF camera. These developments raise the bar for openness. They're indicative of things to come. Lowest common denominator interoperability is what makes IT work. The days of “one off” integration that require a business relationship to facilitate interoperability are leaving this business very quickly. Look at the histories of DEC and IBM for some parallels (hint: one of them "got it").

Finally, Nick (via Facebook) had some counterpoints to Alok Srivastava's pragmatic advice on lessons learned in software development.

Nicholas Jost at 2:38pm June 29
1.) Bogus. We've known for years that key contributors have out sized impact on software projects. This has been proven again and again and is a key part of the "master" model.
4.) Scaling is one thing, performance another. Premature optimization is the bane of software development.
7.) This, at last, is a very important concept. More important because it is true that within an organization different software groups are willing to compete for "coolness" and any process that hampers this competition (notice that this is different from "directing" it) will reduce the innovativeness of a company. Small, fairly independent groups that can talk to each other is a good thing.
9.) Also important but may be culturally nuanced. Software engineers aren't that way by training, they are that way by _nature_. Take the computer away, take the diploma away, and they would be chipping on rocks to make better wheels.

Pedantic off.

But I think "team" was referring to the larger group outside the core software development team that includes support, marketing, sales--all those weirdos. They always seem to be getting in the way of the master's craft, but are a necessary evil if you want to do this stuff for a living. Thus Alok's advice that we invite them to the party--teamwork and all that jazz.

The Green-field is always Greener

Maintaining software is harder than writing it. That's why groups often decide that a complete rewrite is going to be better than rearchitecting or even just maintaining their existing system. Management loves green-field projects because they're a mythical utopia that will provide an opportunity to get everything they want this time.

Ref The Old "Migrate the App" Silliness via But at what cost?

Couple this with the force of "what I don't understand must be broken" and you've often got a recipe for disaster.

What needs to change to make a system better are the tools, techniques, and especially the people. Give the same programmer a different technology and yes you'll get a different app (because the programmer is more experienced now), but you'll also get 80% of the same results.

The Endowment Effect

I recently met with some local software business leaders to discuss how the economy is affecting us. Driving to the meeting, I tried to think up a course of action that makes sense during these times. Best I could come up with were:

• Focus - Remove distractions and concentrate on the narrowest scope of business that has the greatest chance of success. This is an opportunity to make some hard decisions about what you're doing and what you're willing to concentrate on.
  
• Leverage existing success - Go back to your existing installed base and make sure they're happy, and upsell them as much as possible. Do this with existing products rather than the newer, riskier products.
  
• Plan for the future - Assuming your ability to focus and leverage existing success allows you to weather the storm, this will be a unique opportunity to exploit the ensuing landgrab that happens after the weak have been eliminated from the competitive landscape. Don't sacrifice this future investment for some short-term gain.
  

The interesting point is the second, "Leverage existing success." Something about this felt right, but I couldn't really explain why. This morning I was reminded of a psychological phenomenon called the Endowment Effect. This tells me that my existing customers value our relationship and the products I've sold them more than new customers value that same potential relationship and my new products. I'm going to have much better luck leveraging existing customers more than I am acquiring new ones.

We all know that it costs much more to gain a new customer than to service an existing customer. The Endowment Effect underscores the importance of the asset that is an existing, happy installed customer base.

Another point of validation for the third point, to plan for the future, came yesterday by a Harvard Business Review's blogger entitled Prepare Your People for the Upturn. Good advice.

Stakeholders

Rob was complaining this morning on Twitter about how much he hates the company's time tracking system. I think about HR applications from time-to-time, mainly as an example of how *not* to develop an application.

Every HR time tracking application I've ever seen or used has the following problems:

• It is antiquated. Probably designed between five and ten years ago and purchased at a ridiculously high cost, the business cannot justify the ROI to upgrade or replace the system.
  
• It has amazing usability problems. I imagine these systems being built to some spec by an overseas sweatshop under contract. While technically they work, they rarely work well.
  
• It frustrates the crap out of thousands of users every day, but then again, who asked them?
  

The trouble with these systems is that the end-user, as a stakeholder, is rarely considered in the design or purchasing decision.

These applications tend to be the perfect storm of poor design. They are sold to CEO's, HR execs or Finance execs who see them as a necessary evil. These execs know little about the underlying technology, and are ill equipped to do the requirements analysis necessary to clearly articulate their needs to the vendor. They maybe consult their IT people, but then those guys have their own agenda (deployment and operations). They definitely ask the Accountants what they need--since they're the only part of the business that actually has anything to gain from the data the system will collect.

In any system there's a bunch of stakeholders in the mix. In this case the role that will make the purchasing decision, and a few stakeholders who will directly or indirectly use the system (i.e, finance, IT, and the employee). The irony of HR systems in particular is that the user who is most affected by the system in their day-to-day life is rarely consulted or studied in the design or purchase of the system.

Let's say you have a company of 2000 employees. Let's say these employees only need to enter their time once a week, and it only takes them 4 minutes to do it. That's 6933 hours of labor time that's going to be spent in your company each year--just entering time. One would think that those employees would be considered as the single most important stakeholder in the design and purchasing decision of such a system.

So what tends to make these systems so miserable, isn't so much the specifics of their design as much as the fact that the stakeholder who's life is impacted *most* by that design is rarely consulted.

In our business we have a number of stakeholders who need to be considered when designing our products. Not the least of which is ourselves (how will this advance our goals?). We also need to consider our sales channels (what allows them to compete?), our target purchasing decision maker (who's often not the end user), and the end user themselves (whose entire waking life is going to be spent using our product).

What's disastrous is when any of the stakeholders are left out of the design process--or when the priority is wrong. HR systems get this wrong all the time, and it's a shame because it makes Rob's life miserable.

Half

I wrote an article recently that I thought was pretty good. Perfect, in fact. Then I was told that it would need to be reduced by 400 words to fit the company's publication. It was 906 words. Cutting 400 worlds would eliminate half.

I went through every section, paragraph and sentence and figured out how to reduce their respective lengths by half without losing anything important or meaningful. Of course, it was better for the reduction. Clear, concise, to the point. It was exorcized of any passive language. The elimination of adverbs shortened and made it easier to read.

I feared that such a reduction would destroy the piece. Instead it made it better. This lesson reminded me of a previous post on Simplification. Taking my own advice was a healthy exercise.

Using "half" as a complexity reduction target simply feels right. It's aggressive and challenging. When you come out the other side and realize that it's possible, you wonder why it wasn't obvious in the first place.

I recall some advice on travel: when packing for a trip, pack what you think you need, then take half the clothes and twice the money. So true for the scope of software projects as well.

Blogs Are MarCom Without The Cat

See this excellent article from a Cisco blogger on Naked Conversations: Blogging in Global Corporations.

I've heard this before. "We asked MarCom to set up a blog for our company but they can't/won't/didn't because they don't have the budget, don't know how, their dog ate their homework.." Whatever.

Here's the deal. Marketing Communications isn't going to initiate or operate a corporate blog because in most companies MarCom is responsible for the production of communication, not for the communication with customers. Blogs are about communication with customers, with very little to zero production skills required.

Who's responsible for making the phone system work? The phone company. Who's responsible for me calling my wife to let her know I'm going to be late for dinner? Me.

What’s different about blogs is the democratization of mass communication. Years ago if you wanted to get a message out to millions of people you had to engage marketing communications folks because they were the only people with the production and distribution capabilities. But now anybody with an internet connection is capable of publishing content that can reach millions.

Consider the story of Einstein attempting to explain radio:

"You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat."

Blogs are just like marketing communications, the only difference is that there is no cat.

So who's going to run corporate blogs? The people who need to communicate with customers. The CEO, the sales guys, the support guys, the product managers, the engineers, whoever. Who's not going to run corporate blogs? Marketing Communications--because they're the cat.