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.

Microsoft should recognize "good enough"

The good folks in the tech support group came by today and upgraded my Microsoft Office from version 2007 to version 2010. The experience left me wondering why Microsoft bothered to introduce a new version of MS Office.

I understand the reasons for version 2007. It was a big change. It introduced the "ribbon", a new way of presenting the GUI menus to users. It also introduced the MS OOXML file formats, which made reading (and writing) files for MS Office much easier. Customers, third parties, and I suspect Microsoft, all benefitted.

With version 2010, I don't see the big changes. There *are* changes. Small changes. The non-intuitive "Office button" has been changed to a tab for the ribbon, which makes it closer to the old "File" menu that was the standard for GUI applications. The "skin" has changed its color scheme from silvery-blue to silvery-gray. There is a new menu item called "Team", which apparently lets one use Microsoft's Team Foundation Server to store and share documents. (But no connection to Microsoft SharePoint or Microsoft Live -- at least none that I can see.)

So I have to wonder: why release a new version? What's in it for Microsoft? More importantly, how do their customers benefit?

And I am not sure that we even need a new version of MS Office.

I suspect that we (in the app industry) have gotten pretty good at word processing, spreadsheets, and note-taking. Improvements beyond fancy skins will be hard to come by. We can do only so much with fonts, justification, and formulas. (In some ways, Intuit has the same problem with Quicken and Quickbooks. Each year they introduce new versions that are advertised as easier to use. Yet accounting has been around for centuries and we don't really need new, imaginative approaches.)

Looking at the situation from another angle: Word processing and spreadsheets, for the most part, are "gen 2" computer applications, and we are moving to "gen 3" apps.

"Gen 1" applications were the centralized, business oriented accounting and inventory apps, where users submitted well-defined transactions to well-defined central databases and received well-defined reports. "Gen 2" applications are the early PC applications with users controlling their own unstructured data and using it for their own (possibly unstructured) analysis. ("Islands of information", in the 1990s term.) Word processing and spreadsheets fit into this category.

The "gen 3" applications of shared data ("web 2.0", social media) have quite different motivators and usages. LiveJournal, Facebook, and Twitter fall into this group. The earlier applications will not fit into this group, no matter how hard you (or even Google) push.

We're done with serious development of the "gen 2" applications. We've made them "good enough". It's time to move on to new ideas.

Microsoft should recognize that MS Office is good enough. Their history has been one of shipping software when it was deemed "good enough". Yet now that it is a large income stream, they seem determined to maintain it. They need to move on.

Because the rest of us have.

The rate of change

In the good old days, technology changed. (Yeah, it still changes.) But it changed at a slow rate. When computers were large, hulking beasts that filled entire rooms, changes occurred over years and were small. You might get a new FORTRAN or COBOL compiler -- but not a new language -- every half-decade or so. (FORTRAN-66 was followed by FORTRAN-77, for example.)

Today, computers get faster and more powerful every six months. (Consider the Apple iPad, with the second version released prior to a year after the first.) Microsoft has released compilers for C# in 2001, 2003, 2005, 2008, and 2010 -- about one every two years. And not only do we get compilers, but we also get new languages. In 1995, Java was the new thing. In 2001, it was C#. Now we have Ruby, Python, Erlang, Haskell, Scala, Lua, and a bunch more. Not all of these will be the "next big thing", but one (or possibly more) will be.

Organizations can absorb change at a certain rate, and no faster. Each organization has its own rate. Some companies are faster than others. Larger companies take more time, since they have more people involved in decisions and more legacy applications. Small companies with fewer people and "software assets" can adopt new technologies quicker. Start-ups with a small number of employees and a few lines of code can move the quickest.

We're in a situation where technology changes faster than most companies can absorb the change. In most (big-ish) companies, managers don't really work with technology but make decisions about it. They make decisions based on their experience, which they got when they were managers-to-be and still working with technology. So managers in today's organizations think that tech works like a C++ compiler (or maybe a Java JVM), and senior managers think that tech works like a COBOL compiler and IMS database. (I imagine that MBA graduates who have no direct experience with tech believe that tech works as a series of commoditized black boxes that are replaceable at the proper cost.)

This is a big deal. If managers cannot value technology and make good judgements, then the decision-making process within companies becomes political, with different groups pushing for their positions and advocating certain directions. Solutions are selected for perceived benefits and the results can be vastly different from the desired outcome. Mistakes can be very expensive for a company, and possibly fatal to the project or the company.

So what is a company to do? One could hire managers who have deep technical knowledge and keep abreast of changes, but such managers are hard to find and hard to keep. One could create a separate team of technologists to set a technical direction for the company, but this can devolve into a special interest group within the company and create additional politics.

I think the best thing a company can do is set a general direction to keep the company technically capable, to set an expectation of all employees to be technically aware, and to reward those teams that demonstrate the ability to manage technology changes. Instead of dictating a specific solution, look for and encourage specific behaviors.

Stupid wizard tricks

Sometimes well-intentioned designs are less than effective.

For example, the Lenovo "select a PC" wizard on their web site. I am in the market for a laptop PC, and visited the Lenovo web site to view their wares. (I have had good experiences with IBM Thinkpads, so Lenovo has an advantage in the selection process.)

After viewing several web pages and being overwhelmed by the choices of PCs, I chose to use the Lenovo web "wizard" (my term, not theirs) to select a laptop. I had been looking at a netbook PC, and I knew that I did *not* want a netbook PC. I want a full-blown laptop PC. But their product line is larger than I can hold in my head at one time, so I ran their web wizard to ask me questions and pick "the right PC for me".

There web wizard is an awesome construct. It asks lots of questions, and then asks a second round of "balance factor X against factor Y" questions where X and Y are attributes like screen size and battery life.

Finally you get to the recommendation. This is, by scientific analysis of your answers to the multitude of questions, the best PC for you. And for me, the web wizard selected... the exact netbook that I had been looking at before, the one that I knew I did not want!

So here I am with the exact wrong answer. The web wizard, with its tiny brain, has decided that I need a netbook. Yet my gut tells me that I do not want it. What to do?

There is no "make adjustments" option. My only option is to start the entire web wizard (with its multitude of questions) from the beginning. I choose not to go through that again -- now it is an ordeal, not an assistant.

The end result: I did *not* (and to this date have not) purchased a laptop (or any other computer) from Lenovo. This is a :FAIL all around.

The moral for software developers: Use wizards -- that is, one-way selection processes of guided questions -- with care, and when you do, keep them short. The larger picture is to allow the user a degree of control, and the ability to make adjustments. Had the wizard displayed possible answers along the way, and let me narrow the set as I select attributes, I probably would be the owner (a happy owner) of a Lenovo laptop PC today.

Did amazon.com invent cloud computing?

I was the recipient of an interesting idea at the local CloudCamp un-conference.

Amazon.com offers their EC2 virtual servers. At first, it was offered with no guarantees: yeah you can run things on EC2 servers, but they could crash at any time. It was cheap, but not reliable. What was a developer to do?

The price for amazon.com's EC2 service was too low to ignore, so developers did what they always do: they built software around the problems. For cheap servers that could crash at any time, that meant building software that was tolerant of servers "disappearing" at any moment.

That's a big part of cloud computing. With "the cloud", a server can drop off-line at any time. Your application must continue. The initial level of reliability of EC2 was low, and forced developers to think about portable processes, processes that could hop from server to server and continue the work. This idea (along with others) made cloud computing possible.

Prior to the idea of portable processes (and crashing servers), applications were built on the model of "the server is reliable". After EC2, software was built with the idea of "the server is not guaranteed". It's quite a change.

So we may have amazon.com to thank for the cloud.

Hybrid for functional languages

Are there hybrid functional languages? Languages that correspond to the hybrid object-oriented programming languages of C++, Object Pascal, and Visual Basic? A quick survey of the web (if there is such a thing as a quick survey) yields a page (from stackoverflow.com) that lists the following languages: Scala, Clojure, F#, Ruby, OCaml, Common LISP, Nemerle, Smalltalk, and O'Haskell. A few other web pages list these languages as hybrids.

So yes, there are hybrid functional languages. And this is important.

The jump from the "classic" languages of C++, C#, and Java to pure functional languages (Haskell, Erlang) is a large one. We were able to move from procedural languages (C, Pascal, and BASIC) to object-oriented languages (Java, C#) by using hybrid languages as an intermediate step. (A rather expensive intermediate step, as we look back at the mountains of hard-to-maintain C++ code we have created, but it was a step.)

We humans, for the most part and in most situations, tend to do better with small steps. Small changes in our programming languages are more acceptable to us that large changes. (Hence the migration from FORTRAN II to FORTRAN IV to FORTRAN 66 and then to Fortran 77, and not a migration from FORTRAN II to Pascal.)

The hybrid object-oriented languages became popular because they were useful.

I expect that hybrid functional languages will become popular for the same reason. We will want to move to the functional languages, to reduce programming time and improve reliability. The jump to a pure functional language is large, often requiring not only a complete re-write of the application but a re-thinking of our thinking for the application. Hybrid functional languages will allow a more gentle transition to functional programming.

Exactly *which* hybrid functional languages become popular is quite hard to predict. Microsoft will push F#, or possibly extend C# with functional qualities. The Java crowd will like Scala. The Ruby enthusiasts will like... Ruby. I'm not sure what the Apple camp will adopt.

Apple, with its devotion to C, C++, and Objective-C is in an interesting position. There is no clear path to functional programming on the Apple platform. This may present a problem for Apple. (Or maybe not, as they may choose to support a functional or hybrid functional language in the future.)

One level down

A while back, I was build-master for a large project. The project consisted of twenty or so Visual C++ projects ("solutions", in Microsoft's terms) and five C#/.NET projects.

As build master, I had to maintain the build scripts and the system that ran them. The build system itself was a complicated application: A Java program with dozens of classes, XML files for the scripts, and an interface that ran on a web page. Maintaining the build system was expensive, and we chose to re-write the system. The resulting system was a simpler collection of batch files. The batch files looked something like this:


CD project-directory-1
MSDEV /build /solution project-1.sln /project Release
CD ..
CD project-directory-2
MSDEV /build /solution project-2.sln /project Release
CD ..
... repeat for all twenty-five projects

The one feature we needed in the system was for it to stop on an error. That is, if a Visual C++ solution failed to compile, we wanted the build system to stop and report the failure, not continue on and attempt to build the rest of the projects.

Batch files in Windows are not good at stopping. In fact, they are very good at continuing on. You can force a batch file to stop. Here's our first attempt:


CD project-directory-1
MSDEV /build /solution project-1.sln /project Release
IF %ERRORLEVEL% NEQ 0 EXIT /B 1
CD ..
CD project-directory-2
MSDEV /build /solution project-2.sln /project Release
IF %ERRORLEVEL% NEQ 0 EXIT /B 1
CD ..
... repeat for all twenty-five projects

This solution is pretty ugly, since it mixes in the control of the execution with the tasks of the execution. (Not to mention the repetitiveness of the 'IF/EXIT' command.) The problem was pervasive: we wanted our scripts to stop after a failure in any part of the process, not just compiling projects. Thus we needed 'IF/EXIT' lines sprinkled in the early phases of the job when we were getting files from version control and in the later part of the job when we were bundling files into an install package.

After a bit of thought and several discussions, we implemented a different solution. We wrote our own command processor, one that would feed commands to CMD.EXE one at a time, and check the results of each command. When a command failed, our command processor would stop and report the error.

The result was a much simpler script. We took out the 'IF/EXIT' lines, and the script once again focussed on the task of building our projects.

With our new command processor in place, we added logic to capture the output of the called programs. We captured the output of the compilers, the source control utilities, and the install packager. This allowed for an even simpler and more focussed script, since we removed the '>log.txt' and '2>errlog.txt' clauses on each line.

Looking back, I realize that our solution was to move the logic for error detection down one level. It took the problem out of the script space and into the space of the command processing.

Sometimes, pushing a problem to a different level is the right thing to do.

Governing the speed of business

Governance of IT projects ensures that they bring value to the organization, by aligning priorities and coordinating resources for the best value to the organization. They do this by enforcing a set of standard processes for each project. The standards often specify the technology to be used, the project evaluation (including cost/benefit analysis), and the reporting of project progress.

A side effect of IT governance is the slow pace at which projects can move. The governance process includes meetings and conference calls between various groups, and buy-in from the involved teams. All stakeholders are included, from users to testers and support teams. Meetings between all of these groups requires time, and frequently the governance organization schedules meetings on a regular basis (say, once a month) to review project progress and discuss new projects. Projects must live on "governance time", and fit within the schedule of the governance organization. But the benefit is that the project meets the needs of the organization.

So the IT governance process slows projects to ensure quality and coordination.

Interestingly, early steam engines (well, some steam engines) had governors. They were used to limit the speed of the engine. They slowed the engine to ensure that the engine provided the proper power. (Or, one could say "to meet the needs of the organization".)

The problem with (traditional) IT governance is that it slows the project. Any project. Every project.

Traditional IT governance is a bureaucratic process. It obtains quality, coordination, and consistency at the cost of time.

It also constrains solutions to projects of a certain size, or of a size within a certain range of sizes.

IT projects come in all sizes, from the two-person, four-hour "let's try this" to the hundred-person, multi-year global development and implementation projects for thousands of users. But IT governance often uses a standard project template for projects, specifying the general steps for a project, the reporting requirements, and the technologies involved. Any project must go through the governance process, and like Play-Doh being pushed through a mold, the project is shaped into a form selected by the governance group. Small projects are increased to include users and deployment teams. Large projects are divided into smaller ones, to allow for deliverables within the standard timeframe.

In other words, the governance process "normalizes" all projects. Small projects are made standard-size, and large projects are made standard-size too.

This normalization makes sense from the view of the governance committee (who wants to see a consistent set of projects and reports) but not from the view of the business. Let's look at a hypothetical example:

Senior Manager (to project leader): "Customers keep calling and asking for an iPhone app. Can we get something built before the end of the quarter?"

Project Leader: "Possibly. We have a few folks who have been experimenting with iPhone apps. Let me look at schedules and see what I can arrange."

:: one week later ::

PL (to SM): "I can move people from the "Huron" and "Erie" projects, and they could build the iPhone app and deliver it in two weeks. But that means delaying "Huron" and "Erie", and the PMO refused to adjust the schedule for those projects. And even if they did, the standards committee needs two months to review the new tools for iPhone apps before allowing us to use them. And then the security group rejected our proposal, since they have not tested the iPhone in our environment. They want six months (and funding) to build a lab and hire four analysts and a manager for iPhone apps. Oh, and the PMO called and wants to discuss the iPhone app at their monthly project review meetings, and they can fit us in to the schedule in three months."

An idea brought "under control" by the governance process. Standardized and approved.

But perhaps not what the organization needs.

The disappearing notion of storage

In the beginning was the processor. And it was good. But the processor needed data to act upon, and lo! there was memory (in the form of mercury delay lines). But the processor and the memory worked only while powered, and we needed a way to store the data in the long term (that is, when the machine was not powered) and so there came storage devices.

Storage devices evolved along a tortuous path. From punch cards to magnetic tape, from paper tape to DECtapes (which were not quite the same as plain magtapes), and then to magnetic platters that were eventually called "discs".

The path for microcomputers was slightly different. Microcomputers started with nothing, had a short stint with paper tape and cassette tape, took off with floppy disks, then hard disks, and finally (eons later) flash thumb drives and solid-state disks (SSDs).

A computer needs storage because everything that we want to store is bigger than memory. The company's accounts would not fit in the 4K of memory (especially with the general ledger program and tape libraries sitting in memory too) so the data had to live somewhere. Removable media (paper tape, magtape, disks) made for an auxiliary memory of virtually infinite capacity.

But what happens when a computer's main memory becomes large enough to hold everything?

I've made the argument (in another forum) that virtual memory is sensible only when the CPU's addressable memory space is larger than physical memory. If the processor can address 16MB of memory (including all virtual pages) and the computer contains 4MB of memory, then virtual memory works. You can allocate memory up to the 4MB limit, and then swap out memory and effectively use 16MB of memory. But give that processor 16MB of memory, and there is no need for virtual memory -- in fact it is not possible to use virtual memory, since you can never have a page fault. (I'm ignoring the CPU designs that reserve address bits for virtual memory. Assume that every address bit can be used to address real memory.)

Computer memory has been limited in size due to a number of factors, one being manufacturing capabilities and costs. It wasn't possible (read 'feasible with the budget') to obtain more than a paltry few kilobytes of memory. External storage was slow but cheap.

The cost factor has just about disappeared. With solid-state disks, we now have lots and lots if bits. They happen to be organized into an entity that pretends to be a storage device, but let's think about this. Why pretend to be a storage device when the CPU can address memory directly?

Here's what I see happening: CPUs will change over time, and will be equipped with larger and larger addressing capabilities. This will require a change to physical architecture and instruction sets, so I expect the change will occur over decades. But in the end, I expect a computer to consist of a CPU, memory, video, and a network port. No USB ports. No memory sticks. No serial port. No keyboard port. And no hard disk drive. You will load applications and data onto your computer. They will be stored in memory. No muss, no fuss!

Such changes will mean changes for programs. We won't need the elaborate caching schemes. We won't need "save file" dialogs. We won't need disk de-blocking routines or special drivers for spinning metal platters.

Not everything changes. We will still need backup copies of data. We will still need transactions, to ensure that a complete set of changes is applied. We will still need names for data sets (we call them 'file names' today) and we will still need to grant permission to use selected parts of our data store.

So I wouldn't toss the concept of file systems just yet. But be prepared for changes in hardware to rock the boat.