Search This Blog

Showing posts with label Innovation. Show all posts
Showing posts with label Innovation. Show all posts

Tuesday, April 19, 2011

Changing Computing Paradigms

I am observing two paradigms of how to use computers, one new, one old.

The old one, call it the Microsoft Paradigm, is You can compute with the support of a paid expert. A friend called the other day and asked if I knew someone who could fix her computer. I asked what was wrong? Nothing, but her old expert was no longer doing that work.

I call it the Microsoft Paradigm, not because Microsoft did anything wrong, but because 30 years ago, Microsoft was the open computing system. They offered freedom and our whole computing expectation grew up around Microsoft products.

Your option back then? Punch your program on the cards, desk check, and take it to the mainframe. You'll get it back...sometime.

That computing with a retained guru is being replaced by the Google Paradigm, Go ahead, figure out how to do it by yourself. Google Paradigm because there are already too many Web 2.0 Paradigms, and Millennium Paradigm is too broad to apply to computing.

The older paradigm, You can compute with the support of a paid expert, became highly developed, with help desks, escalations, trouble ticketing software, three tier support, and other rites. It made computing everywhere. I admire the druids of this paradigm, they had magic skills, and they like me.

What bothered me was six druids would come up with six fixes for the same problem...and they all worked. Instead of the One True Fix, were we worshiping false fixes?

Eighteen months ago, I wrote how the largest government contractors were already forecasting the end of this paradigm. If we spend our time looking at other people's websites, how much fix can we do?

Over the past 6 years, my paid support got less and less supportive. Often when my computer was bust, I would go back to old notes and propose a previous fix to my druid du jour. It was often new to them. I remember one year when we launched three commercial websites and each time I had to remind the developers to uncheck the box that made it available only to Microsoft Explorer. By the the third website, I could solve that problem in a minute.

For my personal productivity, I had to become fluent in Gmail. For years, the one thing Microsoft Outlook could do that I couldn't do in Gmail was email merge. There were supporting programs, but I wanted the elegant solution.

This winter, supporting a tribe of 200 scientists and technologists judging school Science Fairs for the Washington Academy of Sciences Junior Academy, I used three different methods all native in Gmail. The slickest was Create a Mail Merge with Gmail and Google Docs which had me complete a mailing, from a cold start, in fifteen minutes. Four minute video, and then I panicked, where was the spreadsheet he used? A link, two paragraphs down, and I was good to go. We now have useful technical documentation standards for the non-technical, overcoming the old standard, “Of course it is hard to understand, it was hard for me to program!”

The newer paradigm, Go ahead, figure out how to do it by yourself, is aided when users put their knowledge on the internet, and other users are able to find and use it.

Last night I went to a Google Technical User Group meeting, where Chida had arranged for Google's Saurabh Gupta to show us , Google Apps Script - Begin To End. Google Apps Script allows each user to build what they want, in less time that it would take to explain it to a paid professional.

Naturally, the first time confidence is an issue, but even in The Mythical Man Month, the advice is when building a system, plan to build two, and throw the first one away. Google Apps Script allows you to build and test in minutes, fine tuning in a few more minutes.

Saurabh's parting advice defined the new paradigm. “Apps Script Documentation is great, the Forum is active, the Gallery is large, and the Blog is always changing.”

Join us!
Enhanced by Zemanta

Wednesday, November 11, 2009

Get The Right Start

Why do some projects win and some projects fail?

I have seen back-to-back projects with a great team, in the same area, get opposite results. Several times. I was involved.

I never noticed anyone working less hard, or the window of opportunity changing, or even bad luck.
What I noticed was that in each case, the initial solution idea was either right or wrong.

A wrong idea makes success much, much harder. The principle reason to keep playing with a wrong idea is to try to stumble upon a right idea. If you didn’t get it the first time why would you get it the second time?

I think there is a process to increase your chances of getting the right start.

First of all, there is a concept of work. When I was an industrial plumber I was told to show up with work shoes, a belt, a pocket notebook, a pencil and a knife to sharpen the pencil. I was amazed how many guys couldn’t do that for a week. I favor the classic Architecture, Design, Execution, Evaluation process unless someone is really attached to some other model.

Then there is a way of thinking. Merlin Mann says, “Innovation is starting where the last guy stopped.” I am a big proponent of finding and using contiguous processes that we have used before. I haven’t ever seen a new theory successfully applied by teams the first time they use it.

Frame the problem differently. Very often when a customer has a problem he can’t solve, the problem is not stupid customer syndrome, it is we are defining the problem in an unsolvable way. Taking the time to define the problem differently often means you can get the desired result without inventing anti-gravity. And not having to rent that anti-gravity box saves a lot of money.

My friend Bill Van Dyke says, “Most golf games are won before the first tee.” Unfortunately too many golfers arrive late and hung over and lose right there.

Do you spend enough time getting the right start?

Comments?