Selling Linux

Selling operating systems is tricky. How do you sell something that you can't touch, can't hold, generally gets in the way, and isn't the reason for buying the physical object?

Microsoft sells Windows, but doesn't advertise it. That is, Microsoft offers Windows for sale but its advertisements are generally about other products such as SQL Server or Visual Studio.

Apple sells OSX but like Microsoft, advertises other products like iPods.

Companies such as IBM and Red Hat sell Linux, or more specifically services surrounding Linux.

Geeks "sell" Linux to other computer users, in the sense that they make a sales pitch but they are not getting paid for it.

Here's what's interesting: Geeks use different arguments when selling Linux to fellow geeks and non-geeks.

When convincing a non-geek to switch to Linux, a geek will usually make the following arguments: 1) Linux is reliable and not susceptible to malware; 2) Linux is free (as in zero cost).

When convincing a fellow geek to switch to Linux, a geek may make the above two arguments, but will also make a third argument: "and it's not Microsoft!".

This third argument is different from the previous two, in that it is an emotional argument, not a rational one. Advertising is about emotions, as advertisers learn decades ago. Commercials for cars, beers, fast food, slow food, televisions, and just about everything are based on emotion. The ads tell us about our future life with the product and how happy we will be.

Yet the sales pitch for Linux remains technical and rational. How quaint!

If we want to convince people to try Linux (especially home users), we need to sell to emotions, not technicals. Save the technicals for the geeks -- but throw in the "it's not Microsoft" argument.

Job boards on web 2.0

In technical terms, job boards are medieval.

The purpose of a job board is to connect employeers and candidates, in an efficient manner. Matching employees and candidates is tricky, and the boards that I have seen (and used) do very little to match them.

Boards have two collections: employers and job seekers. Employers must register and create a description of the offered job, and employees can then come and search through the list. Some boards are more sophisticated than others; simple boards list the positions, mainstream boards allow users to search on various criteria (location, skill keyword, date posted), and really savvy boards let job seekers set up agents that perform searches and report results.

The search mechanism is what I find disappointing. It is a keyword-based match, and nothing more. Some job boards allow for multiple keywords and you can specify that all keywords must match. Some job boards fail to recognize certain keywords, such as "C#" or "C++". But the searching is still pretty brute-force.

The problem is that searches yield too many results. A search in a metropolitan area can yield hundreds of matches. One doesn't want to specify too many keywords in fear of locking out a good position that omits a keyword from the description. But too many results is not effective -- after about the twentieth match (of which most are not so great) one's brain becomes fuzzy. The quantity of search results is high. The quality of search results is not so high.

The problem happens on both sides, that is for employers and job seekers. Either can be overwhelmed with responses.

Web 2.0 techniques can help.

Instead of brute-force keyword matches, job boards can let users rate the search responses and use the ratings in future searches. This is the technique used by Netflix to recommend movies.

Instead of movies, job seekers can rate offered jobs. At first (that is, right after registration) the job board knows only the technical skills specified by the user. As the job seeker looks at offered jobs, the user can rate the match and the job board can gain additional knowledge of the job seeker's desired job.

The system works for the employer too, although the job board must keep a set of ratings for each job posted, not a single set. This allows an employer to create a new posting and start with no preset ratings -- which you would want if the previous job was for a COBOL programmer and the new job is for a C# programmer.

The system is not exactly the same as the Netflix algorithm which uses "what other people recommend" -- that method doesn't make sense for job boards. And the overall pool of candidates is changing: as people find jobs they take themselves out of the pool, whereas movies are returned in the Netflix model.

A smarter search should allow for faster matches of employer and job seeker. That is a good thing, if the job board is paid for making such connections. If a job board is paid by advertisers and not by employers or job seekers, then the dynamics change. In that situation, the job board has little incentive for people to find jobs. The incentive is to have people visit the site and see advertisements.

Job boards have been succssful by gaining bulk, that is, the number of openings and the number of job seekers. Some have gained business by using clever advertising. But bulk and advertising is not enough in this world -- you need results. Job boards that deliver lots of poor matches will be at risk of a competitor that delivers fewer high-quality matches.

It's time for job boards to move beyond the medieval approach of brute-force high-quantity results and into the age of intelligent results.

Good coding practices, thirty years on

A friend gave me a set of books, knowing that I am a computer geek. The books were Basic with Style, Fortran with Style, and Pascal with Style and written by Henry F. Ledgard and Paul Nagin. Dating from the late nineteen-seventies, these books summarize good coding practices of the day. We've seen a lot of changes from the days of the Apple ][ and CP/M, at least in hardware and networks. What about software development?

The books present a set of proverbs: good practices for programming.There are about twenty; we can go through them quickly.

NOTE: The three books are really one book, tailored for each language. Object-oriented programmers would say that each is a specialization of a base class. I will consider them as one book, or focus on the proverbsand not so much the individual books.

Proverb 0: "Do not break the rules before learning them." I would have phrased it "Learn the rules, then learn how and when to break them," and I think it is very good advice.

Proverb 1: "Don't Panic." Possibly lifted from the BBC radio production of "The Hitchhiker's Guide to the Galaxy," Ledgard and Nagin advise following a deliberate plan for development. They recommend avoid rushing; later they advocate top-down design and coding. Agile Development encourages a "sustainable pace". Not quite the same, but I think this proverb still holds.

Proverb 2: "Define the problem completely." I'm pretty sure the authors use this in the "requirements first, then design, then coding" sense, which is quite different from the approach used by Agile. In Agile Development, one develops the tests first and then codes. The tests define the problem for the code.

Proverb 3: "Start the documentation early." This proverb contains the assumption that there will be documentation. In Agile, the recommendation is to create only the documents that are needed.

Proverb 4: "Think first, code later." This is the authors acknowledgement of the need for design.

Proverb 5: "Proceed top-down." The authors advocate top-down programming, which requires a design. Agile lets the design grow with the program and does not mandate an up-front design. A partial match with Agile methods.

Proverb 6: "Beware of other approaches." Not content to advocate top-down design and programming, the Ledbard and Nagin warn us away from other coding approaches.

Proverbs 7 and 8: "Code in logical units" and "[Use] functions and procedures [subroutines]". The wording varies here in the three books, following the varying terms used by the different languages. But the sentiment is the same as the modern-day notions of high cohesion and loose coupling. Agile Development doesn't speak of these concepts; it allows development teams to use them as they see fit.

Proverb 9: "Don't GOTO" or "Be wary of GOTO." Here the authors argue for structured programming techniques, something that is accepted as good practice today.

Proverb 10: "Prettyprint." A term that has fallen into disuse. The authors argue for proper indentation and good use of whitespacing, concepts accepted as good practice today.

Proverb 11: "Use mnemonic names." (Not included in the BASIC version, since BASIC at the time had single-letter variable names.) Considered a basic practice today, and anyone not using good names is considered a poor programmer.

Proverb 12: "Comment effectively." The authors argue that comments should have value not merely prescence, something that is not recognized today.

Proverb 13: "Make constants constant." Later languages have good constructs for constants and most programmers (and current texts) use them.

Proverb 14: "Get the syntax correct now." This proverb assumes a non-interactive programming session and the authors mention "turn-around" time, a concept probably unknown to most programmers today. (In the days of batch computing, when you submitted a program for a run and got the results later, the "turn-around time" was the time you had to wait for your results. Interactive programs such as word processors were not possible; all data had to be supplied up front.) With today's personal computers, powerful development environments, and syntax and logic checking in compilers, I think the more effective approach is to let the computer check the syntax.

Proverb 15: "Don't leave the reader in the dust." Here the authors recognize that a program is read by humans more than it is read by computers, an observation made by Gerald Weinberg in The Psychology of Computer Programming. Agile Development advocates refactoring for readability.

Proverb 16: "Produce good output." Today we accept that the requirements will specify -- in detail -- the output. Not so in the nineteen-seventies.

Proverb 17: "Hand-check the program." Another proverb caused by long turn-around times. Instead of syntax, this proverb advocates checking the logic. Perhaps not a bad idea today.

Proverb 18: "Prepare to prove the pudding." Here Ledgard and Nagin provide weak guidance. I suspect that they created the proverbs in a top-down design and had a section for testing and verification. Later when they created the details for the section, they found that they had nothing. The only techniques the provide are "write programs that run correctly the first time" and to use Print statements to display intermediate results. Agile Development mandates automated tests for verification.

Proverb 19: "Have someone else read the work." Not a formal code review but a good start. Also notice that the authors refer to the program as "the work" not "your work", shifting ownership away from the programmer. This was called "egoless programming" by Gerald Weinberg. With Agile Development, the notion of pair programming gives us another pair of eyes.

Proverb 20: "Read the manual again." The authors advocate learning details about the language and the compiler.

Proverb 21: "Don't be afraid to start over." Advice offered by many over time. Agile Development does not advocate a complete re-design but allows it, with the automated tests providing verification support.

So how well do the proverbs hold up? Quite well, I think. Some are dated; they are tied to specific technologies like batch processing.

Which means that we had the knowledge for effective software development back in the nineteen-seventies.

Huh.

Chrome breaks the rules

Some time ago Google released their Chrome browser.

Chrome breaks some rules. I'm not sure that this is a bad thing.

In the good old days of MS-DOS and PC-DOS, files were files and pretty much all files stood on an equal footing. Some files were executable code, some were data, but all were files. Disks held files in a bunch, and there was little in the way of organization. (Savvy users grouped files in directories by application, other users placed all files in a single directory.)

With the Windows age, Microsoft provided an organization to files. Executable files become special and lived in the "Program Files" directory. Users had individual directories and stored private data in those directories. Other directories held common data. (Microsoft made little mention that Unix used similar structures for decades before Windows did.)

Collecting executables in the "Program Files" directory (which was divided into subdirectories for vendor and product) provided several benefits. First, it was a common and agreed-upon place to store executables, which made updates easier. Second, it eliminated (or at least reduced) duplication of files. Third, it provided all executables to all users, allowing Windows to expand its multiple-user capabilities. Fourth, it allowed Windows to govern access to executables, and limit access to privileged users. (Not all configurations did this, but it was common.) Ordinary users found that they could not add or adjust program files. This limitation was a good thing; it prevented many viruses from spreading. Users could manipulate their own data (they had total rights to files in their directories) but not change the executable files.

This model was so strong that even I followed it when I configured systems. I had administrator access to systems, and I added applications into the "Program Files" directory. I did not think about adding them under the user directory; such things just "weren't done".

Google's "Chrome" browser, or more precisely its install program, breaks this rule. The Chrome browser does not live in "Program Files"; it lives in the user directory. This is a significant change. It allows some freedom, but it adds some risks.

First the freedom: By installing in the user directory, Chrome allows anyone to install it. Most Windows systems are configured to allow only an administrator to add or change files in "Program Files", and the average user cannot install programs. Chrome's install ignores that tradition and installs into the user directory, where the user has rights to create files. (To be honest, most programs will let you pick a location for installation; most simply default to "Program Files". Although some want to put selected files in system directories where you need administrator access.) Chrome makes it easy for anyone to install it.

Now for the risks: Executables in your user directory are easily modified. The protection that Windows provides is that you, as a user, cannot modify executable programs. Nor can processes that you start, even if they are infected with viruses. (Viruses often propagate through executable files, not data files.) By locking the "Program Files" directory, Windows shuts down one transmission vector. By keeping executables in the user directory, Chrome opens the vector. (Not to other users; just to your files.)

I'm not sure that this idea (install executables in a user directory) is good. Or bad. I'm thinking that it does not scale well. If every application used this technique, we would be back in the days of MS-DOS and individual directories for each application. On the other hand, each user would have their own set of applications and could control the update of them. Home systems are controlled by the user but corporate systems are controlled by a central administration group. How many of you have had an application (such as MS-Word) upgraded to a new version by your support teams? And did they ask for your permission?

Chrome has broken a rule, for good or bad. It has some interesting consequences. I expect few companies to follow Google's lead; staying with the tradition will serve them well.

The benefit would be to a company that built small, cheap applications and made them easy to buy (perhaps in an "App Store"?) for individuals. Then users -- even corporate users -- could purchase applications and install them on their locked-down PCs.

Does Apple really hate netbooks?

This week's big news is that Apple publicly dissed netbooks. (You know, those smaller-than-laptop-but-larger-than-iPod computers that customers insist on buying.)

Apple made some harsh but perhaps not undeserved observations about netbook PCs: small screens and cramped keyboards were the big criticisms.

Some folks think that Apple hates netbooks. I disagree. I think Apple dislikes the current set of netbook PCs. Computerworl has an article/blog about it.

I'm pretty sure that Apple is studying the netbook sales figures. Heck, Microsoft changed Windows 7 to let it run on netbooks. If a trend gets the attention of the Boys from Bellevue, the folks in Cupertino will watch.

I think Apple wants to bring out a netbook, but isn't quite sure how. One problem is the product line: a netbook would fit above the iPod and iPhone, but below the MacBook. Another problem is the design: should it have a keyboard? An Apple netbook with a keyboard would be a small MacBook (and possibly cannabalize sales). An Apple netbook without a keyboard would be a... Newton! And possibly a big success, with the right applications.

I'm guessing that Apple wants to introduce a tablet PC, something physically larger than an iPod but smaller than the smallest MacBook. It won't have a keyboard. It will have Wi-Fi, run OSX, and build on the 'app store' model from the iPod. It will probably have geo-location services.

Apple will need some time for design and manufacturing, some time for negotiating selected apps to the "Neo-Newton", and some time for marketing. Only some apps will go over, Not everything for an iPod makes sense on a larger tablet.

If you have an iPod app, start thinking big!

Scale of software

A friend and I had dinner in a neighborhood restaurant eariler this week. After dinner, I gave her a short walking tour of the neighborhood. I live in the old part of the city, with houses and churches from the turn of the century. (That is, the previous century.)

My friend commented that the city looked very different when viewed on foot. She was familiar with that part of the city but only while driving in a car, and walking was a new experience for her. The city is different on foot. Or, more accurately, our perceptions of the city are different.

In a car, we move along at twenty-five to thirty miles an hour, and we must pay attention to traffic, street signs, and pedestrians. We have no spare attention for architecture. On foot we can focus on other things. Yes, one must be aware of cars and other pedestrians, but the amount of attention required for them is small. You can spend attention on other things. If you want, you can stop and look at buildings while everyon else goes about their business.

The city (at least the downtown portion in which I live) is designed for pedestrians. It is scaled for foot traffic. Buildings are close; many abut their neighbors. There are sidewalks. Some streets are one-way. The result is that it is easier for me to walk to the grocery store than to drive.

Suburbia is scaled for automobiles. The buildings are placed further apart, and surrounded by parking lots. Some suburban developments have no sidewalks. Suburban malls are often built in areas that are unapproachable on foot.

The scales of city and suburb are different.

Are there similar scaling in software? I think that there are. Software is not scaled along the axis of pedestrians and drivers, but for individuals and organizations. Some software works well for the individual and poorly for a large organization. The traditional PC packages (word processor, spreadsheet) are scaled for individuals and do not allow for collaboration. In contrast, databases are designed for multiple users and database applications are better for teams than individuals.

Instant messaging is scaled for individuals, but small sets of individuals. Instant messaging is useless for a single person; you have to have a partner for messages. But it is limited to two (or maybe three or four) people at a time. 

E-mail is interesting in that it can scale from two users to a large number of users. Two people can use e-mail easily. A team of people can use e-mail with distribution lists.

Microsoft has taken some interesting steps with Sharepoint and their Office suite. They are moving the word processor and spreadsheet out of the single-user realm and into the multi-user realm. This is why they hawk their Sharepoint product as a "collaboration tool".

Most web applications are designed for multiple, collaborating users. PCs are efficient at private information, the web is efficient at shared information.

When building an application, be aware of its scale. Think about the users and their needs. Software built at the right scale will be well-received. Software built at the wrong scale will be ignored.

The Twitter Revolution

The world is a-twitter about Twitter, the new social networking messaging service. It is the current "rave", and I think rightly so. Twitter can bring about significant changes.

First, a brief description of Twitter: a one-way, multi-target, subscription-model instant messaging service.

Instant messaging and its close cousin text messaging are two-way, two-party (occasionally more) messaging services. I can establish an IM session with you and then we can exchange private messages. (Private to the extent that the carriers and eavesdroppers can read them, but others cannot.) Or I can establish an IM session with you and someone else and then the three of us can exchange messages, each seeing what each person sends.

Twitter is different. The first difference is that Twitter is one-way: messages go from sender to recipient with no return messages. Second, Twitter is multi-target and messages can go from one sender to multiple recipients. (Sounds like e-mail without the "reply" button, doesn't it?)

The third difference is what makes Twitter revolutionary: it uses a subscription model. Senders do not pick recipients; recipients pick the senders that they want to "follow". The receiver is in control, not the sender. This is quite a reversal of power.

Corporations could use Twitter to keep people informed of events. (Corporations already use instant messaging, e-mail, telephones, and paper memos, why not Twitter?) I suspect that a corporation would want a private Twitter network, available to employees but not outsiders. But the subscription model used by Twitter is quite at odds from the usual corporate distribution list. The normal corporate distribution list is centrally controlled, and depending on the situation one must ask for permission to be added to a list or perhaps one is put on a list despite one's desires. Twitter changes that thinking, by giving the "opt-in" and "opt-out" choice to the recipient.

With a Twitter service, the sender (or "Twitterer" in the parlance) has no control over the distribution of the sent messages ("Tweets", in the parlance). With e-mail a manager can include all direct reports and exclude members of other teams, with Twitter that is not possible. It is akin to posting the location and time of a group meeting and not mandating specific individuals but allowing anyone to attend.

Changing the corporation's internal Twitter service to allow such forced reciept of Tweets and to limit Tweets to specific individuals would change the Twitter service back into instant messaging with a distribution list. And that is a very different animal. It is a different social contract, one in which control remains with the sender.

Twitter is revolutionary because it places control in the hands of the recipients. It is a democratizing approach, allowing people to select the information that they receive. Telephone calls, e-mail, and paper memos that use sender-maintained distribution lists are dictatorial.

I think corporations will benefit from Twitter. It is not a complete replacement for paper memos and e-mails, or instant messaging. It complements these services. Twitter can replace a lot of status reports and e-mails, and notifications about events (such as test results or group meetings), and it's subscriber model can make the distribution of messages more efficient.

Viva la revolucion!