Lots of folks are unhappy with Windows 8. The complaints are easy to find: just search the web for Windows 8 and skip any pages on microsoft.com.
My take is that Windows 8, and Metro in particular, are the first version of a new product. Microsoft has a history of releasing products that are not quite right, and releasing follow-up versions that improve the product. Eventually, Microsoft releases a product that is popular. I call this the "version 3 effect", after the experience with Windows. Microsoft released Windows several times before it became popular in version 3.0, and really popular with version 3.1.
Resistance to early versions of Windows was due in part to hardware (the processors and PCs of the day were not quite ready for multitasking) and due in part to our unfamiliarity with the new creature known as Windows. (The jump from PC-DOS to Windows was a large one, and it took most people some time to adjust our mental model of PCs.)
I recall a similar resistance to .NET, with people unsure of the new thing and longing for the familiarity of the old MFC/Win32 world. (Some of the confusion was caused by Microsoft's marketing, with tagged almost every product with the ".NET" label.) Yet today we have no confusion of .NET and few developers want to return to Win32 or MFC.
The change from Windows 7 to Windows 8 is a large one. I view it as large as the MFC- to-.NET change and the DOS-to-Windows change. Microsoft has redefined the Windows API and the terms of GUI design. Instead of Win32 or even the classic .NET API, Microsoft is providing WinRT. Instead of the traditional "windows and controls" design, Microsoft is providing Metro.
These changes are large, and more importantly, they invalidate a lot of hard-won knowledge of the Microsoft environment. Developers must learn the new APIs, and much of their current knowledge is about to become useless. This, I think, is driving the anger in the development community. I expect similar anger in related communities: tech support, sales, Windows-as-component (think of the point-of-sale and kiosk systems that include Windows), and anyone who uses Windows. Microsoft has changed the rules, and people have to learn the new set.
I think that Microsoft is doing the right thing. The wrong thing would be to keep Windows as Windows, to not move towards the model of tablet computing. That path would allow Apple, Google, and Linux to surpass Windows and make Microsoft irrelevant.
Metro isn't classic Windows. It also isn't perfect, or even demonstrably better (yet). I expect Microsoft to learn from their experience and improve their product, as they have in the past. If Windows 8 is "version 1", then look for one or two service packs to improve the product -- those will be "version 2". The "version 3" product, the one that gets it right, will be Windows 9.
Saturday, March 10, 2012
Wednesday, March 7, 2012
The C preprocessor is a thing of beauty
Converting programs from one language to another can be easy or difficult, depending on the languages. More specifically, the ease of conversion depends on the commonality of language features.
For example: converting a program from FORTRAN IV to C. Converting a FORTRAN program to C is easy, converting a C program to FORTRAN IV is hard. The FORTRAN constructs of subroutines and functions are easily handled in C, as are the data types of integer, real, and character. C has constructs that are unavailable in FORTRAN: pointers, dynamic memory, and recursion. The FORTRAN language elements of IF/THEN and DO are available in C, but the C elements of 'while' and 'longjmp' are not. (We have to shoe-horn the non-FORTRAN aspects of C into FORTRAN.)
When converting a program from one language to another, the difficulties of conversion are the language-specific features of the 'origin' language -- the things that the 'destination' language cannot handle.
In the past, I have considered the C preprocessor to be a hideous thing, an orc-like programming language that has no manners. But I have been wrong.
The C preprocessor (which is the same as the C++ preprocessor), has some very interesting constructs. It is a language with concepts found only in advanced programming languages. It has access to the caller's scope, something that exists in the lambdas of LISP. It can use a parameter as a substitution token, or it can substitute the text value of the token name into the program ("stringification").
These features of the C preprocessor make conversion to other languages difficult. We think of the C preprocessor as an ugly beast not because it is ugly, but because we cannot easily convert its code to another language. The preprocessor language is beautiful -- simple, elegant, and powerful. We hate it because we cannot think of it in the terms of languages that we know and love.
It may be some time before mainstream languages have the features of the C preprocessor. (I'm considering LISP outside of the mainstream, at least for now.) Until such a time, the advanced language of the preprocessor will pose conversion challenges to programmers.
For example: converting a program from FORTRAN IV to C. Converting a FORTRAN program to C is easy, converting a C program to FORTRAN IV is hard. The FORTRAN constructs of subroutines and functions are easily handled in C, as are the data types of integer, real, and character. C has constructs that are unavailable in FORTRAN: pointers, dynamic memory, and recursion. The FORTRAN language elements of IF/THEN and DO are available in C, but the C elements of 'while' and 'longjmp' are not. (We have to shoe-horn the non-FORTRAN aspects of C into FORTRAN.)
When converting a program from one language to another, the difficulties of conversion are the language-specific features of the 'origin' language -- the things that the 'destination' language cannot handle.
In the past, I have considered the C preprocessor to be a hideous thing, an orc-like programming language that has no manners. But I have been wrong.
The C preprocessor (which is the same as the C++ preprocessor), has some very interesting constructs. It is a language with concepts found only in advanced programming languages. It has access to the caller's scope, something that exists in the lambdas of LISP. It can use a parameter as a substitution token, or it can substitute the text value of the token name into the program ("stringification").
These features of the C preprocessor make conversion to other languages difficult. We think of the C preprocessor as an ugly beast not because it is ugly, but because we cannot easily convert its code to another language. The preprocessor language is beautiful -- simple, elegant, and powerful. We hate it because we cannot think of it in the terms of languages that we know and love.
It may be some time before mainstream languages have the features of the C preprocessor. (I'm considering LISP outside of the mainstream, at least for now.) Until such a time, the advanced language of the preprocessor will pose conversion challenges to programmers.
Monday, March 5, 2012
Bigger than you think
The brave new world of tablets will change business. It will change not just business but the way that we do business.
Managers like to think that they make decisions that drive technology. And they do, to an extent. They buy technologies that make their businesses more efficient and more capable.
But the arrow points both ways. Not only does business drive technology, but technology drives business.
PCs changed the way we do business: In the "Mad Men" world of the 1950s business were run with typewriters, filing cabinets, secretaries; now we run businesses with desktop PCs, servers, and IT support teams.
Managers may like to think that they were in charge of that transition, but much of it was forced upon business managers. Typewriter manufacturers went out of business, filing cabinets became "old-fashioned", and secretaries became luxuries reserved for the uppermost managers. Businesses had to adopt PCs because other businesses were using them, and because previous technologies were expensive. Businesses had little choice in the matter.
The internet and the world wide web changed the way we do business: In the pre-web era companies communicated with customers by letter, phone, possibly e-mail, and in person. The web era allowed companies to communicate with web pages. Customers select their purchases without assistance from salespeople (or telephone order operators). Businesses had to adopt the web because other businesses adopted the web and customers expected it. Businesses had little choice in the matter.
Tablet computing and cloud computing will become big, for individuals and businesses. Businesses will adopt them, because they have little choice in the matter.
Individuals will stop buying desktops and start buying tablets (if they already have not done so). Most PC applications are poorly suited for the individual and home user: no one really needs an office suite with word processing and spreadsheets, and certainly not presentation software. Individuals want Facebook, Twitter, and yes, Angry Birds. They will want smartphone apps and tablet apps for banking and shopping. Businesses that provide these apps will thrive; businesses that don't will see sales suffer.
Businesses will stop buying desktops and start buying tablets because PC manufacturers will stop selling PCs. Or they will allow workers to bring tablets from home, reducing their outlays to zero. Changing to tablets will cause confusion and change for businesses, but it will not drive businesses out of existence.
The shift from desktop PCs to tablets will cause businesses and governments to change their organization. Commercial and government entities have organized their information around spreadsheets, documents, and presentations. But these organizations do not have to organize themselves that way. In the pre-PC era, they organized themselves around weekly and monthly reports from the mainframe. In the post-PC era, they will organize themselves around cloud-based services and tablet-based apps that present data in real-time.
Companies long ago outsourced non-core tasks such as payroll, the generation of electricity, and the production of paper. With tablets and cloud, they can focus their core processes and on continue to outsource non-core tasks. IT support is a likely candidate for outsourcing, as is Human Resource administration.
New companies will form to offer new forms of corporate support. (IT support and Human Resource administration are two areas that come to mind.) These new companies will offer services to other companies, much like web services offer services to other web applications.
Outsourcing is not the only change. Just as PCs allowed large companies to eliminate jobs (such as secretaries), tablets and cloud will allow companies to eliminate more jobs. I suspect that companies will keep the jobs that require creativity and outsource the jobs that consist of rote tasks. The remaining jobs will be closely tied to the performance of the company's core processes.
The brave new world of tablet computing will be different from the current world. I think it will be a better world, with clearer focus on core competencies and "value added". Some folks may find the transition uncomfortable; others will thrive.
Managers like to think that they make decisions that drive technology. And they do, to an extent. They buy technologies that make their businesses more efficient and more capable.
But the arrow points both ways. Not only does business drive technology, but technology drives business.
PCs changed the way we do business: In the "Mad Men" world of the 1950s business were run with typewriters, filing cabinets, secretaries; now we run businesses with desktop PCs, servers, and IT support teams.
Managers may like to think that they were in charge of that transition, but much of it was forced upon business managers. Typewriter manufacturers went out of business, filing cabinets became "old-fashioned", and secretaries became luxuries reserved for the uppermost managers. Businesses had to adopt PCs because other businesses were using them, and because previous technologies were expensive. Businesses had little choice in the matter.
The internet and the world wide web changed the way we do business: In the pre-web era companies communicated with customers by letter, phone, possibly e-mail, and in person. The web era allowed companies to communicate with web pages. Customers select their purchases without assistance from salespeople (or telephone order operators). Businesses had to adopt the web because other businesses adopted the web and customers expected it. Businesses had little choice in the matter.
Tablet computing and cloud computing will become big, for individuals and businesses. Businesses will adopt them, because they have little choice in the matter.
Individuals will stop buying desktops and start buying tablets (if they already have not done so). Most PC applications are poorly suited for the individual and home user: no one really needs an office suite with word processing and spreadsheets, and certainly not presentation software. Individuals want Facebook, Twitter, and yes, Angry Birds. They will want smartphone apps and tablet apps for banking and shopping. Businesses that provide these apps will thrive; businesses that don't will see sales suffer.
Businesses will stop buying desktops and start buying tablets because PC manufacturers will stop selling PCs. Or they will allow workers to bring tablets from home, reducing their outlays to zero. Changing to tablets will cause confusion and change for businesses, but it will not drive businesses out of existence.
The shift from desktop PCs to tablets will cause businesses and governments to change their organization. Commercial and government entities have organized their information around spreadsheets, documents, and presentations. But these organizations do not have to organize themselves that way. In the pre-PC era, they organized themselves around weekly and monthly reports from the mainframe. In the post-PC era, they will organize themselves around cloud-based services and tablet-based apps that present data in real-time.
Companies long ago outsourced non-core tasks such as payroll, the generation of electricity, and the production of paper. With tablets and cloud, they can focus their core processes and on continue to outsource non-core tasks. IT support is a likely candidate for outsourcing, as is Human Resource administration.
New companies will form to offer new forms of corporate support. (IT support and Human Resource administration are two areas that come to mind.) These new companies will offer services to other companies, much like web services offer services to other web applications.
Outsourcing is not the only change. Just as PCs allowed large companies to eliminate jobs (such as secretaries), tablets and cloud will allow companies to eliminate more jobs. I suspect that companies will keep the jobs that require creativity and outsource the jobs that consist of rote tasks. The remaining jobs will be closely tied to the performance of the company's core processes.
The brave new world of tablet computing will be different from the current world. I think it will be a better world, with clearer focus on core competencies and "value added". Some folks may find the transition uncomfortable; others will thrive.
Monday, February 27, 2012
Uglies
Programming has seen a number of ugly things, and we programmers (and more specifically, language designers) have improved them.
The GOTO statement
The most famous ugly thing in programming is probably the GOTO statement. First called out by Edsger Dijkstra in the Communications of the ACM, (description here on wikipedia) it is the poster child of poor programming practices. The GOTO statement was a direct analog of the assembly language "jump" instruction (often assigned the code 'JMP', but it varied from processor to processor), and it allowed for difficult-to-read programs. We improved programming languages with structured programming, 'if/then/else' statements, 'while' loops, and iterations over collections. (The 'goto' statement was omitted from Java, but remains in C, C++, and C#.)
Global variables
Global variables were another form of ugliness, allowing any part of a program to read (or more excitedly, modify) a variable. One never could tell what value a global variable would contain. They were mandatory in COBOL; present in FORTRAN, C, and C++; removed in Java and C#.
Arithmetic IF
FORTRAN has the honor of originating the 'arithmetic IF', a three-destination comparison of a value. (It was not limited to FORTRAN, the thing would show up later in FOCAL.) One of three GOTO statements would be executed, based on the sign of an expression. (The sign could be positive, negative, or zero.) This nasty beast was the result of the IBM 704 instruction set, which allowed such a construct in one instruction. Efficient for the processor, but not so much for the programmers.
Pointers
Pointers were available in Pascal and the life-blood of C. In Pascal (and in C) they allowed the construction of numerous data structures, many of which were impossible in earlier languages. Yet pointers were also a form of "GOTO in data" and lead to lots of headaches. They were eventually replaced by references, which were pointers bound to a known valid entity.
Memory management
The pointers in C (and Pascal, somewhat) demanded memory management. One could allocate memory for anything, but one also had to track that memory and release it when one was finished with it. The later languages of Visual Basic, Perl, Java, C#, Python, and Ruby all replaced manual memory management with garbage collection.
Early garbage collection algorithms were unpredictable and often caused performance problems. Later algorithms (and faster processors) made garbage collection practical.
Column-dependent coding
FORTRAN (and to some extent COBOL) used indentation as a significant indicator to the compiler. FORTRAN was locked into a restrictive format that specified columns for line numbers and statements (and statement continuation on a successive 'source card'). COBOL's view of indentation was more advanced. While optional, it was a popular convention and saw life again in Python's indentation for block definition.
Short variable names
BASIC was initially limited to a single letter and an optional digit. (No 'R2D2' for you!) Original FORTRAN saw variable names limited to six characters. Early PC compilers for BASIC, Pascal, and C had similar restrictions. Modern compilers and interpreters allow for variable names longer than I can care to type (and I type some long names!).
The overall trend
Looking back, we can see that lots of ugly programming constructs were made for efficiency (arithmetic IF) or due to limitations of memory (short variable names) or processing power (GOTO). Advances in hardware allowed for work to be shifted from programmers to compilers, interpreters, and run-time systems. But here's the thing: advances in programming languages and techniques are much slower than advances in hardware.
Today's computers are more powerful than those of the 1960s by several orders of magnitude. While replacing GOTO with structure programming and replacing direct memory management with garbage collection, the change in software is much smaller than that of the change for hardware.
I'm tending to think that this effect is caused by the locality of software. We programmers are close to our programs; the hardware is remote, sitting on the far side of the compiler. We can, should we choose, replace the hardware with faster (compatible) equipment or switch to a new target processor by changing the back end of the compiler. In contrast, the programming language constructs are close to us, living inside our heads. We think in our programming languages and are loathe to give them up.
Moreover, we programmers often learn to overcome the ugly aspects of programming languages and sometimes develop techniques to leverage them. We become attached to these tricks, and we are quite reluctant to let them go.
If we want to advance the art, we will have to give up the old (ugly) constructs and adopt the new techniques. It is not easy; I myself have had to give up BASIC for C, C for C++, and C++ for Java and C#, and C# for Ruby. I have given up unstructured programming for structured programming, structured (procedural) programming for object-oriented programming, and object-oriented programming for immutable-object-programming. Each transition has been difficult, in which I had to un-learn the old ways. Yet I find that the new languages and techniques are better and allow me to be more effective.
The GOTO statement
The most famous ugly thing in programming is probably the GOTO statement. First called out by Edsger Dijkstra in the Communications of the ACM, (description here on wikipedia) it is the poster child of poor programming practices. The GOTO statement was a direct analog of the assembly language "jump" instruction (often assigned the code 'JMP', but it varied from processor to processor), and it allowed for difficult-to-read programs. We improved programming languages with structured programming, 'if/then/else' statements, 'while' loops, and iterations over collections. (The 'goto' statement was omitted from Java, but remains in C, C++, and C#.)
Global variables
Global variables were another form of ugliness, allowing any part of a program to read (or more excitedly, modify) a variable. One never could tell what value a global variable would contain. They were mandatory in COBOL; present in FORTRAN, C, and C++; removed in Java and C#.
Arithmetic IF
FORTRAN has the honor of originating the 'arithmetic IF', a three-destination comparison of a value. (It was not limited to FORTRAN, the thing would show up later in FOCAL.) One of three GOTO statements would be executed, based on the sign of an expression. (The sign could be positive, negative, or zero.) This nasty beast was the result of the IBM 704 instruction set, which allowed such a construct in one instruction. Efficient for the processor, but not so much for the programmers.
Pointers
Pointers were available in Pascal and the life-blood of C. In Pascal (and in C) they allowed the construction of numerous data structures, many of which were impossible in earlier languages. Yet pointers were also a form of "GOTO in data" and lead to lots of headaches. They were eventually replaced by references, which were pointers bound to a known valid entity.
Memory management
The pointers in C (and Pascal, somewhat) demanded memory management. One could allocate memory for anything, but one also had to track that memory and release it when one was finished with it. The later languages of Visual Basic, Perl, Java, C#, Python, and Ruby all replaced manual memory management with garbage collection.
Early garbage collection algorithms were unpredictable and often caused performance problems. Later algorithms (and faster processors) made garbage collection practical.
Column-dependent coding
FORTRAN (and to some extent COBOL) used indentation as a significant indicator to the compiler. FORTRAN was locked into a restrictive format that specified columns for line numbers and statements (and statement continuation on a successive 'source card'). COBOL's view of indentation was more advanced. While optional, it was a popular convention and saw life again in Python's indentation for block definition.
Short variable names
BASIC was initially limited to a single letter and an optional digit. (No 'R2D2' for you!) Original FORTRAN saw variable names limited to six characters. Early PC compilers for BASIC, Pascal, and C had similar restrictions. Modern compilers and interpreters allow for variable names longer than I can care to type (and I type some long names!).
The overall trend
Looking back, we can see that lots of ugly programming constructs were made for efficiency (arithmetic IF) or due to limitations of memory (short variable names) or processing power (GOTO). Advances in hardware allowed for work to be shifted from programmers to compilers, interpreters, and run-time systems. But here's the thing: advances in programming languages and techniques are much slower than advances in hardware.
Today's computers are more powerful than those of the 1960s by several orders of magnitude. While replacing GOTO with structure programming and replacing direct memory management with garbage collection, the change in software is much smaller than that of the change for hardware.
I'm tending to think that this effect is caused by the locality of software. We programmers are close to our programs; the hardware is remote, sitting on the far side of the compiler. We can, should we choose, replace the hardware with faster (compatible) equipment or switch to a new target processor by changing the back end of the compiler. In contrast, the programming language constructs are close to us, living inside our heads. We think in our programming languages and are loathe to give them up.
Moreover, we programmers often learn to overcome the ugly aspects of programming languages and sometimes develop techniques to leverage them. We become attached to these tricks, and we are quite reluctant to let them go.
If we want to advance the art, we will have to give up the old (ugly) constructs and adopt the new techniques. It is not easy; I myself have had to give up BASIC for C, C for C++, and C++ for Java and C#, and C# for Ruby. I have given up unstructured programming for structured programming, structured (procedural) programming for object-oriented programming, and object-oriented programming for immutable-object-programming. Each transition has been difficult, in which I had to un-learn the old ways. Yet I find that the new languages and techniques are better and allow me to be more effective.
Saturday, February 25, 2012
Upper case and spaces
Early written language (that is, natural language) used only upper case letters and no space characters. The space was a medieval invention. In the ancient world, the phrase "texts from the ancient world" appeared as TEXTSFROMTHEANCIENTWORLD. Our concepts of "upper case" and "lower case" come from Renaissance times, with the invention of movable type and two cases to hold the slugs for letters.
The original art of writing was to simply record the phonemes, allowing the reader to re-create the spoken sounds. Text was for re-enacting a speech, not storing information. The notion of "reading to one's self" had yet to emerge. A reader was little more than a modern-day tape recorder in playback mode, generating sounds for the audience (the true readers of the text).
It is interesting that the development of our programming languages parallels the development of written natural language.
Early programming languages used upper case letter in their character set. This was true for FORTRAN, BASIC, COBOL, assembly language, and other languages. As IBM card punches and readers used a limited character set with only uppercase letters, we can see that language design followed the available equipment.
Some early programming languages did not care about space characters. FORTRAN was space-agnostic; the parsing of the language was independent of SPACE characters. One could write
THETA = 10.0
DO 9 I = 10,20
ALPHA = BETA * I
SUM = ALPHA + SUM
9 CONTINUE
or one could write
THETA=10.0
DO9I=10,20
ALPHA=BETA*I
SUM=ALPHA+SUM
9 CONTINUE
the FORTRAN compiler would treat them identically. (FORTRAN did care about columns 1 through 7; the first six were reserved for line numbers and column 7 was reserved for the continuation indicator.
Such space-agnostic parsing was not unique to FORTRAN. Early versions of the BASIC language were space-agnostic. (Such was not the case for COBOL or assembly language, both which relied upon SPACE characters to separate tokens.)
In time, we humans learned that written (natural language) text could be read silently, and that space characters improved the readability of the text. Similarly, we human programmers learned that space characters improved the readability of programs (as did blank lines and indentation) and that programs should be read, and should be written to be read. (See The Psychology of Computer Programming by Gerald Weinberg.) While it took several centuries to invent the concept of a space to separate words in natural language, we adopted the concept of whitespace in programming languages in less than a decade.
If we consider spaces and indentation the marks of advanced program-writing, then that leads to the conclusion that the language which uses spaces and indentation most is the most advanced programming language. The languages that use spacing and indentation most, as I understand it, are Python (with its indentation for marking code blocks) and assembly language (with its heavy reliance on spacing and indentation for parsing). All other language fall after those two.
Friday, February 17, 2012
No sleeping giant for cloud computing
I suspect that a lot of people are waiting for a "grand convergence" of the different forms of cloud computing, or a "market leader" to define a standard that everyone (or just about everyone) can use. Such an event occurred in the PC market, when IBM released their model 5150 PC into a frothy market of multiple architectures and standards.
While today's cloud environment is similar to the 1980 microcomputer market, with multiple vendors and varying "takes" on cloud computing (infrastructure as a service, platform as a service, software as a service), I'm not expecting a single approach to dominate the market.
The thing that we are missing is the "sleeping giant", the one large, well-respected company that had not entered the market. With microcomputers, that sleeping giant was IBM. Hundreds of small companies (and not so small companies) were selling into the market. Apple, interestingly, was one of them. The products varied, from fully assembled, ready-to-run systems (Radio Shack) to kits (Heathkit) to assemble-your-own-kit offerings. No one company was dominant, or even close.
But IBM was out there, and everyone knew it. IBM waited and picked a fortuitous time to enter the market. Their reputation (and product) defined a center for the market, a common ground, a mainstream.
With today's cloud market, the major players are involved. IBM is in, mostly for corporate and large customers. Microsoft is in, with Azure. Amazon.com is in, Google is in, and Apple is in. These companies have developed (and continue to develop) their offerings. There are no folks waiting on the sidelines for the opportune moment. (At least, no large, well-respected companies.)
Thus, I see no equivalent to the IBM PC for the cloud market. I see no one product or service offering that will take the market by storm.
Instead, I see the market remaining fragmented. I suspect that a few players may change (Oracle may buy Rackspace, for example) and some smaller players may gain ground. But no sleeping giant to "set the world straight".
While today's cloud environment is similar to the 1980 microcomputer market, with multiple vendors and varying "takes" on cloud computing (infrastructure as a service, platform as a service, software as a service), I'm not expecting a single approach to dominate the market.
The thing that we are missing is the "sleeping giant", the one large, well-respected company that had not entered the market. With microcomputers, that sleeping giant was IBM. Hundreds of small companies (and not so small companies) were selling into the market. Apple, interestingly, was one of them. The products varied, from fully assembled, ready-to-run systems (Radio Shack) to kits (Heathkit) to assemble-your-own-kit offerings. No one company was dominant, or even close.
But IBM was out there, and everyone knew it. IBM waited and picked a fortuitous time to enter the market. Their reputation (and product) defined a center for the market, a common ground, a mainstream.
With today's cloud market, the major players are involved. IBM is in, mostly for corporate and large customers. Microsoft is in, with Azure. Amazon.com is in, Google is in, and Apple is in. These companies have developed (and continue to develop) their offerings. There are no folks waiting on the sidelines for the opportune moment. (At least, no large, well-respected companies.)
Thus, I see no equivalent to the IBM PC for the cloud market. I see no one product or service offering that will take the market by storm.
Instead, I see the market remaining fragmented. I suspect that a few players may change (Oracle may buy Rackspace, for example) and some smaller players may gain ground. But no sleeping giant to "set the world straight".
Sunday, February 12, 2012
Redmond may be the new Detroit
Microsoft is haunted by its reputation.
In the 1960s and 1970s, Detroit earned a reputation for a certain level of quality in its products. Cars were designed, built, and sold -- lots of cars, since U.S. automakers had no significant competition -- with a level of quality that was ... less than it could have been. Cars were designed with "planned obsolescence", built to last for a few years or a few thousand miles. Exhaust systems would rust, vinyl roofs would shred, and gas mileage was low. But with no competition, Detroit had a quasi-monopoly on the market. (There was some competition from automakers in Germany, France, and Japan, but it was small.)
In the late 1970s, the price of oil (and therefore gasoline) rose, and people became unhappy with their cars. Japanese automakers designed and built cars that were efficient. Those cars were also reliable.
Japan quickly acquired the reputation of building reliable, efficient cars. Detroit acquired the reputation for "gas guzzlers" and shoddy workmanship.
Detroit learned a hard lesson, changed its ways, and built better cars. They were more efficient, safer, and more reliable. Detroit improved the quality of its product and now produces cars that are of equal quality to Japanese cars.
Yet the reputation lingers.
Within companies, the sales and marketing folks are very conscious of "the brand" and do things to maintain the companies "image". They run advertising campaigns and conduct customer surveys. Reputation is the customer's version of brand management. It's not managed, it simply happens. Whatever customers think of your brand becomes your reputation. And Detroit earned the reputation for unreliable and inefficient products.
Which brings us to Microsoft.
Microsoft is the Detroit of the software world. It has a long reputation of building buggy, bloated applications. And until recently, it was the only game in town -- if you were using computers, you were using Windows. (A few rebels used Apple or Linux, but they were on the fringe, much like the folks who drove foreign cars in the 1960s.)
Just as the Japanese automakers moved in to the American market, Apple moved in to the PC market. Apple now has a significant share of PC sales and software sales. (Linux remains fringe, except in the server arena.)
Detroit changed its ways, and Microsoft is making changes to Windows. The Windows 8 line, with its "Metro" GUI and the Windows App Store, is a big departure from the old Windows. The old Windows provided a platform (Windows), office software (Word, Excel, Exchange, Outlook), development tools (Visual Studio) but left the market open to all others. Anyone could write and sell applications for Windows (and many people did). Windows PCs were open in the sense that the owner (or administrator) could install applications from any source - Microsoft, third-party providers, or even in-house developers.
The brave new world of Windows 8 changes that. Apps (at least, apps for the "Metro" side of Windows 8) must come through the Windows App store, much like iPad apps must come through iTunes. This change will allow Microsoft better control over the quality of apps, and allow it to filter out poorly-written apps and malware. It improves the quality of apps in the Windows environment.
With these changes, Microsoft may be able to achieve a level of quality that equals (or perhaps even surpasses) that of iPad apps.
Which brings us to reputations.
Will improved quality be enough for Microsoft? Or has the market assigned a reputation to Microsoft? The reputation of buggy software may limit Microsoft's growth.
For Microsoft to succeed in the market, they must provide software of a higher quality than Apple, and they must build a reputation for reliable software.
I believe that they can do it. But I believe that it will take a lot of control over the products that are released in the Windows world. A level of control that is on par with Steve Jobs' obsession with quality. And I am not sure that the existing market of Windows application providers is ready for that.
In the 1960s and 1970s, Detroit earned a reputation for a certain level of quality in its products. Cars were designed, built, and sold -- lots of cars, since U.S. automakers had no significant competition -- with a level of quality that was ... less than it could have been. Cars were designed with "planned obsolescence", built to last for a few years or a few thousand miles. Exhaust systems would rust, vinyl roofs would shred, and gas mileage was low. But with no competition, Detroit had a quasi-monopoly on the market. (There was some competition from automakers in Germany, France, and Japan, but it was small.)
In the late 1970s, the price of oil (and therefore gasoline) rose, and people became unhappy with their cars. Japanese automakers designed and built cars that were efficient. Those cars were also reliable.
Japan quickly acquired the reputation of building reliable, efficient cars. Detroit acquired the reputation for "gas guzzlers" and shoddy workmanship.
Detroit learned a hard lesson, changed its ways, and built better cars. They were more efficient, safer, and more reliable. Detroit improved the quality of its product and now produces cars that are of equal quality to Japanese cars.
Yet the reputation lingers.
Within companies, the sales and marketing folks are very conscious of "the brand" and do things to maintain the companies "image". They run advertising campaigns and conduct customer surveys. Reputation is the customer's version of brand management. It's not managed, it simply happens. Whatever customers think of your brand becomes your reputation. And Detroit earned the reputation for unreliable and inefficient products.
Which brings us to Microsoft.
Microsoft is the Detroit of the software world. It has a long reputation of building buggy, bloated applications. And until recently, it was the only game in town -- if you were using computers, you were using Windows. (A few rebels used Apple or Linux, but they were on the fringe, much like the folks who drove foreign cars in the 1960s.)
Just as the Japanese automakers moved in to the American market, Apple moved in to the PC market. Apple now has a significant share of PC sales and software sales. (Linux remains fringe, except in the server arena.)
Detroit changed its ways, and Microsoft is making changes to Windows. The Windows 8 line, with its "Metro" GUI and the Windows App Store, is a big departure from the old Windows. The old Windows provided a platform (Windows), office software (Word, Excel, Exchange, Outlook), development tools (Visual Studio) but left the market open to all others. Anyone could write and sell applications for Windows (and many people did). Windows PCs were open in the sense that the owner (or administrator) could install applications from any source - Microsoft, third-party providers, or even in-house developers.
The brave new world of Windows 8 changes that. Apps (at least, apps for the "Metro" side of Windows 8) must come through the Windows App store, much like iPad apps must come through iTunes. This change will allow Microsoft better control over the quality of apps, and allow it to filter out poorly-written apps and malware. It improves the quality of apps in the Windows environment.
With these changes, Microsoft may be able to achieve a level of quality that equals (or perhaps even surpasses) that of iPad apps.
Which brings us to reputations.
Will improved quality be enough for Microsoft? Or has the market assigned a reputation to Microsoft? The reputation of buggy software may limit Microsoft's growth.
For Microsoft to succeed in the market, they must provide software of a higher quality than Apple, and they must build a reputation for reliable software.
I believe that they can do it. But I believe that it will take a lot of control over the products that are released in the Windows world. A level of control that is on par with Steve Jobs' obsession with quality. And I am not sure that the existing market of Windows application providers is ready for that.
Subscribe to:
Posts (Atom)