Microsoft's Vista blindspot

Microsoft has dedicated a whole website to try to convince people that Vista isn't so bad after all. The problem actually repeats one of Keough's descriptions of how he fell for replacing Coca-Cola with New Coke. His commandment is trusting outside experts, but what you really see is with New Coke you had user studies that showed people liked New Coke more in blind taste tests. What they missed is that people had an emotional connection with the old Coke, regardless of the sweeter taste.

Here Microsoft is missing that the issue with Vista is not the usability in a vacuum, it is what happens when you try to get it work with your legacy applications and hardware. No drivers, problems, upgrades required, and so on and so on. They don't test for that in their experiment.

This study has all the feel of some attempt at internal political justification, and not actually marketing a product anyone wants.

And I say this as someone who runs Vista and has no issue with it.

The most important UI design advice you will ever get

Follow it and your users will thank you forever. Or even better praise - they won't notice at all, because it is so obvious to them that this is how it was supposed to work.

When static typing just won't do

Although I'm a fan of static typing, when calling web services, it just doesn't make sense. The amount of effort expended to typing the WSDL to make the code compile is already high, and then add the maintenance cost, it just gets unbelievable. Compare this in Ruby on Rails, compared to what it would take with axis. The difference is just obscene.

The only obvious conclusion is that you may run your code inside a JVM, but use JRuby or something else that is dynamic for the web services calls, if you have any significant web services to use.

The long term solution has to be to make the compiler understand a WSDL and do the static checking against that. It won't help if you want to dynamically discover web services at runtime, but that is really a separate problem from just needing to consume a web service in an application.

Know your business

Via Instapundit we have this timeline of Wikipedia vs. the AP.

The problem for the AP is that they (should have) a lower tollerance for getting it wrong. I'll leave it to them to address their specific business problem, but the general lesson is to know your business, and not try to compete on the other guy's terms. Wikipedia has the luxury of a reputation which forgives inaccuracy under the premise that it is easily corrected. AP lacks that advantage, so instead of competing on speed, it needs to compete on its strength.

Many companies are afraid of this kind of competition, because it creates what is called differentiation, and when you are different, you risk losing business even if you execute flawlessly, because the market demanded what made the competition different from you, instead of the other way around. It is much easier to play it safe, especially with a boss, or a board, that will have no problem just retroactively deciding that being different was a bad decision. Playing it safe means being just like the other guy, just doing it better, or being able to hide behind the excuse that any failure wasn't do to execution of the concept, because you see your product competes feature for feature.

It is those that are in a position to take that chance, that can become the next Google.

When your business model is interupted

Here is a failure of imagination. No one knows how to make money on the Internet, or so conventional wisdom goes (don't tell them), so a business can reach millions more people, and lose more money. Like the music business, it is a failure to realize the changing realities and adjust to them. Of course, I wouldn't know how to make money in the business, which is why they don't pay me several million dollars a year. But there is clearly money to be made. They just forgot that their core selling point to consumers is hard-core news, not opinion.

Vista's problem

So Microsoft sends out a list (via it's Microsoft at Work RSS feed) of the 10 top things about Vista. That is a very anemic list. With the exception of Windows Areo, everything on that list can be done in XP. And this is their top 10. No wonder they are having so many problems with it. It is Windows ME without the backwards compatibility.

Being pragmatic is good business

Let's face it, being pragmatic is always good business. The only time being idealistic is good business is when the market demands idealism. And then that is simply the pragmatic choice.

Dynamic typing and the IDE

In further researching dynamic vs. static typing, the obvious question is how can the IDE make you productive, suggest method names, if there is no such thing as an invalid method name at compile time? How can it show you the documentation behind the code, if it has no idea what that method name will actually resolve to?

One way is to analyze all the code that calls the method. Some new languages are doing that to guess the type without you having to spell it out.

But it can't help you create a missing method in the correct class, because it wouldn't know where it is supposed to go.

Dynamic typing is great for scripting, where a script is defined as something that is not large enough to be a problem to erase and recreate when it gets out of hand. In such a context, static typing is overkill.

In a larger project, with many different developers and more limited channels of communication, I'm still looking for how to overcome the problems. So far it seems that people just shrug off the problem as small in practice. I suspect that their practice involves more serious and disciplined programmers than a lot of us have the luxury of working with.

UPDATE: I guess integrating something like this would allow the IDE to understand what is going on. Of course that doesn't exist yet.

I can say from experience that having a method that cannot be safely renamed will cause larger projects to not have their methods renamed, causing the code to age. You might hope that a bad "search and replace" refactoring would get caught by unit tests, but if the search and replace was thorough, then it wouldn't. It would just be impossible to rename the method in a specific context.

Much to learn

So I'm investigating Ruby on Rails (vs my more extensive background in Java) and I see this quote:

A solid suite of unit tests is every bit as good, if not better than, static-type checking. Because all you want in type checking is confidence that you haven't made the basic mistakes. A good set of unit tests will provide that for you.

I'm wondering what I am missing? The most common mistake in the lack of type checking is outside the unit. One class makes the mistake of calling this other class and they don't understand the type of the variable. Most commonly, it changes after it was first written. In fact, that is why those with a preference for dynamic typing like so much - you can change it so easily and just add a method.

So here I have a series of Unit Tests that check for one thing on one object, and a series of unit tests that make sure that when an external object is called, it will be called with the right parameters. Then I go and change that other class and all of its unit tests. How do I validate that all calling code kept up? A text search? But method names can be duplicated all the time.

I just don't get how static typing of an interface is not the only way to ensure that changes are propogated throughout the project. Of course many times you don't have that luxury (like when you are calling web services). But it seems like a good thing to have, unit tests or not.

The perils of customer service

Authorize.net took a dive in this web designer's view.

It just goes to show how a company can ruin 9 years of good service in two weeks. Two lessons:

1) The fact that someone wants to stop a current relationship doesn't mean they stop being an important customer. Treat them as such.

2) Your customers expect perfection. Aim to deliver.

Fortunately these days most companies don't differentiate themselves in customer service, so you don't have to work to hard to match them.

Of course you can never please everyone, and having an unhealthy need to please can be very distracting and unproductive. But here a great reference (and you have to think there are many more than one) was lost because of a drop in customer service. It matters, but companies don't know how to sell it, so they often skimp on it.

My worst experience was with a company that sold, for money, it support services (called Maintenance). When you called support you got someone with an Indian accent who didn't know, and who's manager didn't know, the meaning of the work "migrate." And this was a service they sold over and above the price of the product. The even solicited the business after we had let the maintenance laps. They won't get my recommendation again, even if their product is technically superior to the competition.

Conflicting Information

Courtesy of Slashdot we have this:

The study used energy company records from Indiana before and after that state mandated DST for all of its counties, and calculated that the switch cost Indiana citizens $8.6M per year. 'I've never had a paper with such a clear and unambiguous finding as this,' the professor said.

The recent changes to DST cost business an untold amount of grief, with old unsupported operating systems needing to be upgraded or patched by third parties just to deal with it, and even new software not functioning correctly until the patches are downloaded. So what lesson does a business learn from this?

One lesson is certainly that clear analysis is more important than acting on conventional wisdom. But more importantly, sometimes there are no clear answers. This is where leadership in business is so important. The leadership to decide when the evidence isn't all in and isn't attainable, and the leadership to stand behind that decision and make it work – but more importantly the leadership to know when something isn't working, and changing course where needed.

Government is not a business, and can't be expected to learn these lessons. But a business can, and should. Have you ever been on a project that was started under a premise that turned out to be false, and when that became known, it was more important to finish the project than to stop throwing good money after bad and admit that things were not as they seemed?

In a culture of blame, making such a decision is impossible. In a culture of accountability, where leaders are responsible to make the right decisions for the business based on the best facts they can get, a business can do so much better.

Undefined purpose

In Bob Lewis' book, he speaks about the importance of a project having a purpose. Often, in fact, a project has a purpose, but the purpose is vague. Especially in technology, people know that technology can lead them to great places, but they skip the part of thinking about how to get there. So it can look like a project has a great purpose, but place holders can become goals.

For example, a company may want to have very flexible software to be able to flexibly control business logic without development, increasing revenue by allowing the business to adapt quickly, and reducing on-going development costs. It will then decide that having a good workflow will help with this (the place holder).

Half way into the project, the workflow becomes the purpose, but the software ends up being very development intensive when it comes to the interaction with the user. The workflow, however, functions great. The goal was too hard, so a proxy was put in its place.

And the project was a great success, but not at doing anything anybody wanted.

IT Flexibility

Bob Lewis asks how if it is practical for IT to provide Virtual Machines as sandboxes for users to experiment with.

On the core question, it may have to do with your user base. If you run a business with technically inclined staff, it would probably work very well. If, on the other hand, you are in a more typical company where one or two people per department are savy enough to set up that access database, the people who might leverage that access database would probably be challenged by dealing with a whole seperate operating system on top of their current machine.

You also have some serious security considerations - and what do you do if that access database needs to touch some data too sensitive to expose to the sandbox?

The bottom line is there is no good substitute for good IT leadership, where part of IT's mandate is to provide tools for users to inovate and improve the operations of the company through technology.

Web 2.0

One thing I never appreciate is the latest buzzword. By the time "Web 2.0" became a buzzword, everyone had a hard time explaining it. In a nut shell, it is this. It is the top watch site right now, and it clearly tries to drive the sale of watches online. Its selection is much weaker than #2 and #3, but those two pay Google for their ranking via lots of Pay Per Click advertising.

Enthusiasts want to do more on your site than just shop. Let them.

The Bounce Rate

A great lesson in what you don't want to see. How many times do you look at a web site you are designing and have no idea what people really see. When you focus on something, it is hard to see it from the casual person's perspective. But does your organization have the open mind to admit when something isn't working, or are the metrics about rationalizing decisions already made, because it would make you look bad to make a mistake?

An organization that doesn't take mistakes as learning opportunities is an organization which is not taking every opportunity to improve. But such an organization is teaching a lesson: we learn how to bury our mistakes so that we don't have to learn from them.

And burying mistakes rarely improves the bottom line.




What does this have to do with bounce rate? Bounce rate is a failure rate, and failure rates are really the metric we can learn the most from - it is about learning from our mistakes and making things better.

The Beginning

The inspiration for the name of the blog is a quote from Maimonides:

Accept the truth from whatever source it comes

Sometimes we hear the truth from unexpected sources - and we need to be prepared to hear it. The ability to distill correct information and act on it is the most powerful tool anyone will have in life.

This blog will explore the implications of that in business and in life.