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.