Kindle

Amazon.com has released the Kindle, a hand-held reader. Kindle works with electronic versions of books. Amazon.com would like you to purchase books through them, but Kindle allows for books in Mobipocket and plain text formats, and Amazon.com provides utilities to convert HTML, MS-Word, JPEG, GIF, PNG, and Microsoft BMP to its proprietary format.

Now, let me say that the name 'Kindle' strikes me as a poor choice for anything to do with books, and an especially poor choice for the elimination of paper books. Yes, I know that Amazon.com want to 'kindle new ideas' but this is not the market for that name. The name 'Kindle' conjures up visions of book-burning.

While Kindle includes The New Oxford American Dictionary, it's not clear that it comes with a copy of Bradbury's Farenheit 451. (Its also not clear that F451 is even available for the Kindle. Amazon.com has set up the Kindle web site to allow searches by bestselling, price, customer review, or publication date, but not by title or author. Possibly searching by title or author would emphasize the limited number of titles available. Amazon.com needs to fix this.)

I suspect that the true audiences for the Kindle are college students and textbook publishers. Certainly the younger crowd is faster to use new tech and adopts it more readily. (But they also may have higher expectations, be more critical, and be more likely to reject a 'dud' technology.)

Textbook publishers win in several ways. They have a shorter time to market and reduced costs. They can sell new versions of their books every year. They also shut down the used textbook market, driving up annual sales.

Losers in this scenario will be the students who buy used textbooks. Since you are not allowed to transfer Kindle books (at least the Amazon.com-proprietary ones), students will have to pony up for the full cost of a new book.

Losers may also include society in general: People other than students buy used textbooks. I have purchased old, used textbooks, because they present information better than today's textbooks. (And because they are cheap.) Textbooks (and other books, and printed items in general) are our civilation's collective memory. If textbooks move to the electronic format, we lose a bit of that memory. Paper lasts longer than electronic patterns and requires less maintenance. I can read books from ten, twenty, fifty, and even one hundred years ago. Will we be able to read Kindle-2007 format books ten, twenty, or fifty years from today?

Microsoft's view

One of Microsoft's advertisement for its Visual Studio product bothers me. For a while, didn't know why. After a bit of thought, I may have identified the cause.

The advertisement (a two-page ad) has in large, all-capital letters: "IT TOOK A THOUSAND YEARS TO BUILD ROME; YOUR DEV TEAM HAS A MONTH" In smaller type, it says "DEFY ALL CHALLENGES" "Your challenge: finish big projects eons faster." "Defy it: communicate and collaborate better with Visual Studio Team System."

I will overlook the grammatical and idiomatic errors in these claims. Instead, let's see what this advertisement tells us about the thinking in Redmond.

The ad shows a view of four modern-day individuals (one assumes that they are project leaders or "software architects") overlooking the construction of two large buildings in a city that one is apparently supposed to believe is Rome.

The "project leaders" are viewing the work from an elevated platform. They are high enough to see all of the work, or a broad scope of the work. They cannot see details. While Microsoft has armed them with a laptop and a cell phone, they have no telescope or binoculars to get a detailed view of the work.

The work is performed with wooden scaffolding, ramps, ropes and pulleys to move heavy stones up the ramps, and cranes with large-scale hamster wheels in which men walk and thereby power the crane. Individuals doing the work are small, numerous, and indistinguishable.

Here's what I get from this advertisement:

- Projects are big
- Managers are important
- Managers must see the work being done (but they don't need to see details)
- Managers use modern tools
- Managers ought to be at high levels

OK so far? Here's the next batch:

- Workers use primitive tools and methods
- You need few managers for many workers
- Workers are interchangeable
- Individual workers are unimportant

The ad repeats the 'think big' philosophy that Microsoft has had for some time. Microsoft has focussed on solutions for large companies and has lost the mindset (and the ability) to deliver solutions for small teams.

I thought that this attitude was driven by greed and arrogance. Greed, in that larger companies can afford larger and more expensive technologies. Arrogant, in that Microsoft was walking away from the individuals, the hobbyists, and the small companies that made them successful.

But perhaps Microsoft did not discard the ability to provide solutions for small teams. Perhaps it was taken away from them. Small teams can use open-source tools and technologies (Linux; Apache; MySQL; and Perl, Python, or PHP) and deliver effective solutions. They don't need Microsoft, and Microsoft is hard-pressed to compete with those technologies. The small guys may have been the ones to walk away, leaving Microsoft with nothing but the big guys.

If that's the case, then it is not greed and arrogance. It is desparation.

Hungarian Notation

I've never liked Hungarian Notation.

No, that's not true. I used my own form of Hungarian Notation in certain C programs (for a certain company). Looking back, I'm not too proud of the  programs. They were inexpertly written, and the strange naming conventions did nothing to improve readability.

I'm pretty sure that the programs have been retired.

I have been reading Numerical Methods and FORTRAN Programming, a work from 1964. It describes programming in FORTRAN and lists (obliquely) the rules for variable names and function names in FORTRAN-IV. They are:

 - Variable and function names are at most six characters
 - Variables of type REAL must begin with a letter in the set A..H, O..Z
 - Variables of type INTEGER must begin with a letter in the set I..N
 - Function names, if longer than three characters, must end in 'F'
 - Variable names cannot end in 'F'
 - Function names must begin with letters that follow the variables, for their return types

These are Hungarian Notation rules, or at least very close in thought. The name of the variable (or function) tells you the data type.

They are different from today's Hungarian Notation, which is a convention agreed to by programmers on a team (or for Visual Basic, a whole industry). These rules are baked into the language! In FORTRAN-IV (and I specify the 'IV' part), you don't declare variables, you simply use them, and the name tells the compiler the type.

FORTRAN 77 came out with a number of improvements, the biggest being the logical IF statement and the dropping of mandatory Hungarian Notation. (Oh, you could still use it, but you could override the "I-through-N are integers" rule. And the 'functions must end in F' nonsense disappeared.)

FORTRAN 77 came out thirty years ago. It had the sense to drop Hungarian Notation. When will the rest of us?

The latest in programming lanugages

Here is late-breaking news about programming languages. The newest, spiffiest, got-to-have-it language is out. It's called LOLcode.

The name comes from the internet LOLcats, since the language is based on their dialect of English. To my knowledge, this is the only programming language based on English since COBOL.

Here is a sample program:

HAI
VISIBLE "I can has cheezburger?"

I HAS A VAR ITZ 1
VISIBLE "I do count!"

IM IN YR LOOP
   VISIBLE VAR
   IZ VAR BIGGER THAN 19 O RLY?
      YA RLY
         GTFO
      NO WAI
         UP VAR!!1
   KTHX
KTHX

KTHXBYE

Like COBOL, all keywords and variable names are in uppercase. And like COBOL, it is meant to be 'readable'. Unlike COBOL, it is meant to be readable by today's up-and-coming internet-savvy, text-phone-using teens, the programmers of tomorrow.

This just may be the next big thing for programming.

Remember, you saw it here first!

Heresy 1: Agile is not fast

It may be a heresy, but I will state it:

Agile Development is not faster than waterfall development.

Programmers using Agile techniques are not faster at adding functionality (or requirements, or function points, or any metric you care to use) than developers using waterfall project planning.

As I see it, Agile techniques offer two advantages: consistent levels of quality and the ability to change you mind. With Agile techniques, the 'test before code' practice ensures that you have tests in place and that all new features work, without breaking existing features. The close contact with users and small steps in development (avoiding the large, "think of everything at once and in the beginning" plans of waterfall) lets you decide on the features to add late in development.

Waterfall makes you commit to functionality up front. Typically, the development organization asks the user organization for a list of changes (in order of priority), estimates the effort for each item, estimates available capacity, and then negotiates on the list of items for the release. This list becomes "the commitment" which is then judiciously guarded by the development organization against changes from the user community.

Agile lets you defer "the commitment" and in fact breaks it down into smaller commitments, usually every week or two. The user community can think about new features and postpone the decision to add them. Rather than one big list decided up front, the list starts small and then adds items in small spurts.

But I see nothing in development practices that make developers go faster. (Well, there are benefits from the test-driven practices, but a waterfall-planned project could use test-driven practices for adding features, so there is nothing unique to Agile.) Programmers add code (features, requirements, function points, what-have-you) at the same rate as development.

I believe that Agile Development is perceived as faster than most waterfall projects, from the effects of test-driven development and the ability to change feature sets. I believe that many users are frustrated with the "committed feature set" of waterfall development (probably the day after the commitment) and welcome the time-delayed possibilities of Agile.

But in the end, the number of features added will be about the same.

So it is not actual performance, but perceived performance that makes Agile development seem faster.

What Techies want

Techies are not so hard to understand. Their wants are simple. Christine Comaford, back in the 1980s, listed four things that techies want:

1) Lavish praise
2) Fun projects to work on and fun tools to work with
3) Free beer and pizza
4) Some money

I liked this list so much I stole it. I repeat it when I can (always giving Ms. Comaford-Lynch credit).

I also modified this list. My modified version is:

1) Lavish, genuine praise
2) Fun projects to work on and fun tools to work with
3) Free beer and pizza, although perhaps not for dinner every night
4) Some money

People (non-techie people, that is) are surprised at the position of money. And at the qualifier "some". Techies don't want lots and lots of money. In general, they want enough to live in reasonable quarters, pay for things like food and the phone bill, and have enough left over for books, music, games, and a few other vices.

It's not that hard.

Lock-in is the new lock-out

What is 'lock-in'? Lock-in is the use of proprietary formats as a way of retaining customers. Microsoft does this with their MS-Word and MS-Excel file formats. The formats are closed, known only to Microsoft and those companies they choose to include in partnerships. But Microsoft is only one example, and I'm not going to pick on Microsoft.

The problem is not limited to Microsoft, and not with Microsoft. The problem is the idea: Lock customer data in a format (or a "prison cell") where only the software from one vendor can read it (has the "key" to unlock the "cell").

So passe! So twentieth century!

Locking data inside an application relies on trust (or naivete) on the part of the customer. A long time ago, IBM salespeople would meet with businessmen, review their use of IBM mainframes and peripherals, and then decide on the next 'generation' of equipment that the business should use. The IBM sales team decided this, alone, not with the customer company. They would then present their recommendations to the customer and frequently the customer would buy everything recommended. The customer trusted the IBM team to recommend the right equipment. (And probably did not have the expertise to disagree.)

Those days are gone. Today, customers for mainframes are savvy and have a keen eye on expenses. And they can pick from a variety of mainframe vendors. When your customers have options, they will pick those options that favor them.

Customers don't (necessarily) want open standards... but they do want to move information from one place to another. Whether documents, spreadsheets, databases, or .mp3 files, customers want to use their data in multiple places, with multiple applications. And they become frustrated when they cannot.

Locking data into a proprietary format can be done when you have a monopoly or near-monopoly. Microsoft has done well with its Office suite, where data is locked inside difficult, if not opaque, file formats. And while some groups have had modest success reverse-engineering those formats, there is always the spectre of incompatibility. The lure of 'file format compatibility' has kept many customers in the Microsoft camp. But a good portion of them chafe. They will jump ship when a new option appears on the horizon. (Some of them will jump simply to get away from the oppressor. But the reason doesn't matter... they leave.)

Microsoft is big and has a commanding presence in the market, and even they have felt the pressure to open their formats. Smaller companies, or companies with smaller market shares (and those companies without 'market power') would be well advised to stay away from the 'lock-in' strategy. It is better to compete on features, usability, and performance.

Of course, that's harder than designing an opaque file format. But I didn't say it would be easy.