The Opposite of Batch

We of the PC revolution like to think that the opposite of big, hulking mainframes are the nimble and friendly personal computers of our trade. Mainframes are expensive, hard to program, hard to use, and come with bureaucracies and rules. Personal computers, in contrast, are affordable, easy to program, easy to use, and one is free to do what one will with the PC -- the only rules are the ones we impose upon ourselves.

Yet mainframes and personal computers have one element in common: Both have fixed resources. The processor, the memory, the disk for storage... all are of fixed capacity. (Changeable only by taking the entire system off-line and adding or removing components.)

Mainframes are used by many people, and the resources must be allocated to the different users. The batch systems used by large mainframes are a means of allocating resources efficiently (at least from the perspective of the hardware). Users must wait their turn, submit their request, and wait for the results. The notion of batch is necessary because there are more requests than computing resources.

Personal computers provide interactive programs by providing more computing resources than a single person requires. The user can start jobs (programs) whenever he wants, because there is always spare capacity. The processor is fast enough, the memory is large enough, and the disk is also large enough.

But personal computers still offer fixed capacity. We rarely notice it, since we rarely bump up against the limits. (Although when we do, we often become irritated. Also, our personal systems perform poorly when they require more resources than available. Try to boot a Windows PC with a completely full hard disk.)

The true opposite of batch is not interactive, but flexible resources -- resources that can change as we need them. Such a design is provided by cloud computing. With cloud computing, we can increase or decrease the number of processors, the number of web server instances, the memory, our data store -- all of our resources -- without taking the system off-line. Our computing platform becomes elastic, expanding or contracting to meet our needs, rather than our needs adjusting to fit the fixed-size platform. Perhaps a better name for cloud computing would have been "balloon computing", since our resources can grow or shrink like a balloon.

This inversion of shape -- the system conforms to our needs, not our needs to the system -- is the revolutionary change offered by cloud computing. It will allow us to think of computing in different ways, to design new types of systems. We will have less thought of hardware constraints and more thought for problem design and business constraints. Cloud computing will free us from the drudgery of system design for hardware -- and let us pick up the drudgery of system design for business logic.

With cloud computing, IT becomes a better partner for the business. IT can enable faster business processes, more efficient supply chains, and better market predictions.

The rise and fall of page numbers

How important is the page number? It is a small thing, and we often read often overlook the page numbers of our texts. Yet page numbers are a relatively new invention.

A long time ago (a very long time ago), knowledge was passed on through the oral tradition, with scholars memorizing and speaking. There was no writing (and therefore no pages or page numbers).

A long time ago (not quite as long as the age of memorization) we humans started writing. We quickly developed parchment and the dominant form was the scroll -- a long piece of parchment that was rolled.

In the first century B.C.E. the codex gained popularity. Instead of a single scroll of parchment, the codex consisted of a set of flat pages. Often made of papyrus, it had the virtue of being two-sided. One could write on both sides of the papyrus. (One could write on both sides of a scroll, but it was not practical.)

Page numbers were introduced in the sixteenth century B.C.E., to aid in cross-referencing documents.

That's a long time for a new concept to arise, especially to our twenty-first century treadmill of new products.

But back to page numbers. E-readers -- a twenty-first century doodad -- make life difficult for page numbers.

It is not pages that lead to the invention of page numbers, but pages with consistent text that make page numbers useful. Every time you refer to the page, the text must be the same as the time before. Without this consistency, page numbers are useless.

E-readers break that consistency. While different editions of a book might use different layouts (and therefore different page numbering), once a printed book was printed, the page numbers stayed put. But e-readers play by a different set of rules. They allow for different sizes of text, so the "pages" they present on their displays change. A document of ten pages in small typeface may be twenty pages in a larger typeface.

Page assignments in printed books are static; page assignments on e-readers are dynamic. Or in the current programmer lingo, printed books use early binding for page numbers and e-readers use late binding. ("Binding" in the "assignment" sense and not the "leaves and signatures into a folio" sense.)

Interesting, this problem did not arise with word processors. I suspect that is because word processors are used more for composition and less for reading, while e-readers are used primarily (if not solely) for reading. Wordstar, Wordperfect, and Microsoft Word are all quite good at assigning page numbers, mostly as an afterthought. For the author, page numbers are nothing more than a bit of stuff that is tacked on at the end.

I suspect that we will see the demise of page numbers. Their original purpose -- cross referencing -- is really a matter of marking destinations within the text, and we can do that with hypertext links and other techniques. Page numbers were a compromise, the best that was possible with the technology of the day, a hack that happened to work.

We still need the ability to refer to specific locations within texts. With other techniques, we can drop page numbers. Oh, I expect that they will stick around for a while. As long as we use printed documents for reference we will need page numbers. I expect a new class of completely on-line information to use pageless (or page-number-less) formats.

While page numbers will disappear, the two structures that currently depend on them (tables of contents and indices) will remain. These are useful, and they will change into structures that can get us quickly to the desired place of the document. They will do it without page numbers, though.

Structure thy data

In the 1980s movie "Labyrinth", there is one scene that shows an image of David Bowie carved in rock. The camera shifts, and you see that the image was actually an illusion. It is not a single rock with the image carved, but three different rocks each with a piece of the image. When viewed from the exact right angle -- when the three rocks line up, and you see the image. When viewed from a different angle, the image disappears.

The movie "The Incredibles" has a scene that does the same thing, but in reverse. Mr. Incredible, in a cave, is looking at a set of rocks. As he shifts his position, writing carved into the rocks forms the word "Kronos". The word is visible from only one position in the cave.

In both movies, data is visible from a specific position, but not from others. This affect can happen to real-life data too.

For example, document files can contain headings, paragraphs, and tables. The data contained within the document often looks good to a human viewing the document, but is difficult (or perhaps impossible) to read by another computer system.

I'm not talking about file formats, and the difficulties in parsing .DOC and .PDF formats. Difficulties in parsing certain file types do exist, and have been reduced by the use of XML-based formats. But beyond the reading of formats, there is the challenge of extracting the structure of the data.

Documents contain headers, paragraphs, and tables. In order to properly interpret and process a document, you must identify these different parts of the document. To identify the parts of the documents, the information in the file must be present. And with our current tools and techniques, there is in way to ensure your document has this structure or verify that another author's document contains this information.

The "proper" way to create a document with this information (in, say, Microsoft Word) is to use styles to mark different parts of the text. Marking the document heading as "Heading" and section and sub-section headings as "Heading 1" and "Heading 2" places this meta-information in the document.

The "improper" way to create a document is to ignore styles and use low-level font commands to change the appearance of text. One can change the typeface, the weight, and the size of text. For each section heading, one can set specific options for typeface attributes. Its less efficient than using styles, but perhaps easier to understand.

I put the words "proper" and "improper" in quotes because there is no standard for using Microsoft Word (or other word processors). One is free to use styles or the low-level commands. And this is part of the problem. But I will ignore the need for best practices and focus on the aspect of data alignment.

Documents using the "proper" method (styles), contain meta information that can be used by other applications to interpret the documents. Documents using the "improper" method have no certain way of interpreting data. (One can make assumptions based on certain patterns, but it relies on consistency in the application of low-level formatting commands.) The data is unstructured.

Unstructured data is like the rocks in "Labyrinth" and words on rocks in "The Incredibles". From the exact right angle, the image is visible. But from any other angle, the image is not. The unstructured data in a document is visible and sensible to a human looking at the text rendered by the word processor on a screen (or on a printed page), but is not sensible to a computer program.

We have achieved much in the development of computer programs. Not just word processors, but spreadsheets, databases, accounting systems, instant messaging, image manipulation, and many more applications. We are at a point (and possible past it) that we should tolerate unstructured data. We should use structured data and encourage it when structured options are available.

Data endures, often long beyond the life of the applications that created the data. To rely on the original programs to read the data is foolish. To assume that only humans will read the data is arrogant.

Getting social media right

A lot of companies have jumped on the social media bandwagon, from Facebook to Twitter to what-have-you. And a lot of companies have gotten it wrong.

They mistake social media as another path for them to send information to customers and potential customers. And one certainly can do that. (With the benefit of knowing that the people following you are actually interested in your products and services.) But that's where a lot of companies stop.

It's a rather arrogant approach, thinking that everyone will be listening to you, with nothing to say of their own.

The companies that really "get" social media will be doing two things: First, they will be talking to people (and not at them). Second, they will be listening.

Social media lets everyone talk. If you really want to leverage social media, recognize its potential for communications from you to your customers, from your customers to you, and from customers to other customers.

Listening to your customers. Now, there's a novel idea!

Microsoft Office becomes hip because Facebook did

The new Microsoft Office 2010 edition has a number of improvements, ranging from animations on the opening splash screen to collaborative capabilities. Microsoft Outlook has a special feature, one that I have not seen in the other products of the suite.

Microsoft Outlook has a social networking feel to it, with incoming e-mails showing avatars of the sender and their immediate network. That's a neat trick, since few people in our office have the latest version of MS Office, and therefore have had no opportunity to set up a social network. (And to be honest, the avatars are all generic "shadow" avatars.)

But this is a change to look like a social network without actually being one.

It turns out that you as the user don't define your social network in MS Outlook -- the software uses the organization's network defined in the Active Directory server. People are members of departments (or groups, or branches, or whatever) and MS Outlook relies on this structure. Which means that the social network image of MS Outlook is just that: an image. It's not my social network (where I can friend and unfriend people), it is the company's definition of a social network: the people in my assigned organizational unit.

It looks cool, until you realize what's happening. Is this an attempt at making a staid (dare one say "quaint") interface more hip? is it a way to make MS Outlook more acceptable to the generation that was raised on Fascebook? Perhaps.

Hipness aside, this change demonstrates that Microsoft felt compelled to change Outlook. Perhaps the change was driven by the collaboration capabilities, but I feel that Microsoft is attempting to compete with Facebook. Which means that Facebook is driving the design of software, not Microsoft.

Improve quality of code by changing staff

In the not-so-distant past, I worked on a small project and reviewed staffing with the project manager. The project was a C++ application that was a component in other systems within the organization.

The code and the procedures were complicated. A new member of the team required at least six months before he or she could be productive, and often the "ramp up" time was closer to a year.

I discussed many issues with the Project Leader. At one point, we discussed the expected tenure of a team member. We agreed that it should be about five years.

Simple math shows that for an average tenure of five years, a team of ten people should "rotate out" two people every year. This project manager did not understand that calculation. More specifically, the Project Leader was unwilling to "swap out" two people of the team that year. This makes some sense, since the two replacement folks would require the better part of the year before becoming productive.

And swapping out another two people in the next year would mean that another two newcomers would need the better part of a year to come up to speed. With my "average tenure of five years" plan, every year would see two newcomers and those newcomers would require time to become familiar with the procedures and the technologies of the project.

So while this Project Leader agreed with the idea of a five-year tenure for team members, she wanted to keep people on the project as long as possible -- and more than five years. Extending the tenure of a person on the project reduced the cost of training a "newbie".

Yet a set of newcomers may be a good thing for a development project. (And perhaps any type of project.)

With a steady influx of new members (and a steady departure of experienced folks), a project must make accommodations for the newcomers. When a project is so complicated, and so difficult to learn, that it takes the better part of a year before a professional skilled in the craft can be productive then adding team members is expensive. The desire to hold on to experienced staff is large.

A project that has a lower "ramp up" cost is better prepared to accept newcomers.

So is the "ramp up" cost high because project difficult to learn. or is the project difficult to learn because there are few newcomers (and therefore little incentive to design the project to be friendly to newcomers)?

The implicit assumption is that the complexity of a project is an innate quality of the project, a result of the requirements and technology. I don't think that is quite true.

Let's turn the idea on its head. Let's work with the premise that the complexity of a project (its processes and its code) is an attribute of the project and one that can be managed, much as the total cost, delivery schedule, quality, and total effort. Therefore, the complexity of a project can be controlled by the project managers. As an attribute, the complexity can be measured and reviewed, and managers can direct changes to ensure that the complexity stays within expected values.

If managers can control the complexity of a project, then they can control the "ramp up" cost for new team members.

Of course, managing the complexity of a project means adding it to the other attributes of a project. There is no free lunch, and devoting effort to one attribute means less effort to other attributes. Reducing complexity may mean less effort for quality assurance, or less effort for support. It may even mean a longer development cycle.

I'm not saying that complexity can be managed for free. I'm asserting that complexity is an attribute of a project can can be managed. How one trades off effort of one attribute against another attribute is what project management is really about.

The end of phone calls?

Is it possible that we are seeing the end of phone calls? The notion is hard to accept. Many companies, government organizations, and individuals run on phone calls.

Here's what I see:

Voice calls are a generational thing The "younger generation" (anyone under 30) uses cell phones, and uses cell phones a lot. But most of the use is text messages. Followed by taking (or sharing) pictures. Followed by surfing the web. Voice calls are way down on the list of uses. Folks over 30 make voice calls; folks under 30 send text messages.

Organizations use voice calls within the organization They use e-mail and some voice for conversations outside of the organization. Organizations use e-mail for communicating with people in other time zones.

Voice calling is cheap The typical phone plan offers some number of free minutes (300, 550, 700... the plans vary) but most folks use only a fraction of their free minutes. In the early days of cell phones, users and vendors worried about minutes of usage (it was all voice calls back then). Today we have enough minutes in the plan. We don't worry about minutes. Voice calls, essentially, are "free", which means that there is little demand for them.

Vendors are focussing on data, not voice The big debates are now about data caps and throttling. Voice minutes and coverage are not part of the debate.

Voicemail makes voice calls asynchronous A traditional voice call is synchronous: both parties must be present and participating at the same time. With voicemail, one party can leave a message and the second party can respond at a later (more convenient) time. Voicemail converts phone calls to the time context of e-mail.

Voicemail as a tactic Companies have been using voicemail for decades, as have individuals. Individuals are now using voicemail tactically, allowing calls to "roll over" to voicemail even though they could answer the phone. I myself let my home (wireline) phone go to voicemail all of the time; family and friends know to call me on my cell phone, so a call to the home phone means someone other than family and friends.

But not everyone is abandoning phone calls. Here are the people and organizations who are still using voice calls:

Political campaigns Every few years, the polit-callers make their cases.

Advertisers Despite being on the "do not call" list, some companies call -- and some leave messages.

Recruiters Some send e-mails, and some call. Even after I gently nudge them towards e-mail, the ones who call continue to use voice calls. This may be a extrovert behavior, where folks prefer talking over written communication.

I generally find that I do not want to answer the phone. Odds are that the call will be an annoyance.

I also find that I have little reason to call a person. I will call a company for a specific reason (to activate a credit card, perhaps) but I make few phone calls to friends. Calls to family are often to the older folks who are reluctant to use text messages.

I think that the lesson here is: all good things come to an end, and when a technology becomes free, it is close to its demise.