We don't need no stinkin phone numbers

Why do we need phone numbers? If you ask the average person, they will tell you that you need a phone number to call someone. I'm not sure that we need phone numbers.

A phone number is an interesting thing. What's more interesting is what it is not: it's not an attribute or property of a phone. That is, there is nothing in your phone (I'm thinking old-style land-line phone here) that knows its phone number. 

And that makes sense. I can take my land-line phone, unplug it from my house, carry it to your house, plug it in, and use it. When I do, calls made are charged to your phone number (your account) and not mine. The fact that I'm using the handset from my house doesn't matter.

One can view a phone number as an address, a target for phone calls. This is a pretty good description of a phone number. The phone jacks in your house are bound to a "pair number" at the central office, and a phone number is associated with that pair number. This level of indirection allows the phone company to move phone numbers around. For example, when my sister moved from one house to another in the same town, she kept her phone number. The phone company simply associated her phone number with the pair number associated with her new home.

Cell phones have a similar arrangement. There is no pair of copper wires running to a cell phone, obviously, but each phone has a unique identifier and the phone company associates your phone number with that identifier. Once associated, the phone company can route calls to your phone based on the identifier.

Another view of a phone number is that it is an instruction to a switching system. Specifically, an instruction to the public switched telephone network (PSTN) to connect you to a particular phone. This is a slightly more useful concept, since it binds the phone number to the switching system and not the device.

Binding the phone number to the switching system means that it is an artifact of the switching system. If we replace the switching system, we can replace the phone number. This is precisely what Skype does, and I suspect competing systems (Vonage, Google Phone) do the same thing.

With Skype, you don't need phone numbers. Instead, you use the Skype ID. I'm on Skype, and I can talk with other Skype users. To connect to another Skype user, I need only their Skype ID -- no phone number is necessary. The Skype switching system can connect us with just the ID.

Skype does let me call people who are not on Skype -- people on the PSTN. To call them, I *do* need a phone number. But this is not Skype's requirement; it is a requirement of the PSTN. (If you want to talk to anyone through the PSTN, you must provide a phone number.) When Skype takes my call and routes it to the PSTN, Skype must provide the destination phone number.

Just as phone numbers are instructions to the PSTN, and Skype IDs are instructions to the Skype switching system, URLs are instructions to the web system. (The switching system for the web is perhaps a bit more complex than that of the PSTN, as the web has multiple layers of addresses, but the concept is the same.)

We may soon see the decline of the phone number. It works for the PSTN, but not for other systems. Other systems (the web, Skype, Google Phone) have no need of phone numbers, other than to connect to the PSTN. If we abandon the PSTN for other systems, we will also abandon phone numbers.

The return of frugality

We may soon see a return to frugality with computing resources.

Ages ago, computers were expensive, and affordable by only the very wealthy (governments and large companies). The owners would dole out computing power in small amounts and charge for each use. They used the notion of "CPU time", which was the amount of time actually spent by the CPU processing your task.

The computing model of the day was timesharing, the allocation of a fraction of a computer to each user, and the accounting of usage by each user. The key aspects measured were CPU time, connect time, and disk usage.

The PC broke the timesharing model. Instead of one computer shared by a number of people, the PC let each person have their own computer. The computers were small and low-powered (laughingly so by today's standards) but enough for individual needs. With the PC, the timesharing mindset was discarded, and along with it went the attention to efficiency.

A PC is a very different creature from a timesharing system. The purchase is much simpler, the installation is much simpler, and the administration is (well, was) non-existent. Instead of purchasing CPU power by the minute, you purchased the PC in one lump sum.

This change was significant. The PC model had no billing for CPU time; the monthly bill disappeared. That made PC CPU time "free". And since CPU time was free, the need for tight, efficient code become non-existent. (Another factor in this calculus was the availability of faster processors. Instead of writing better code, you could buy a new faster PC for less than the cost of the programming time.)

The cloud computing model is different from the PC model, and returns to the model of timesharing. Cloud computing is timesharing, although with virtual PCs on large servers.

With the shift to cloud computing, I think we will see a return to some of the timesharing concepts. Specifically, I think we will see the concept of billable CPU time. With the return of the monthly bill, I expect to see a renaissance of efficiency. Managers will want to reduce the monthly bill, and they will ask for efficient programs. Development teams will have to deliver.

With pressure to deliver efficient programs, development teams will look for solutions and the market will deliver them. I expect that the tool-makers will offer solutions that provide better optimization and cloud-friendly code. Class libraries will advertise efficiency on various platforms. Offshore development shops will cite certification in cloud development methods and efficiency standards. Eventually, the big consultant houses will get into the act, with efficiency-certified processes and teams.

I suspect that few folks will refer to the works of the earlier computing ages. Our predecessors had to deal with computing constraints much more severe than the cloud environments of the early twenty-first century, yet we will (probably) ignore their work and re-invent their techniques.

Measuring the load

If I worked for a large consulting house, and offered you a new process for your software development projects, would you buy it?

Not without asking a few other questions, of course. Besides the price (and I'm amazed that companies will pay good money for a process-in-a-box) you'll ask about the phases used and the management controls and reports. You'll want to be assured that the process will let you manage (read that as "control") your projects. You'll want to know that other companies are using the process. You'll want to know that you're not taking a risk.

But here's what you probably won't ask: How much of a burden is it to your development team?

It's an important question. Every process requires that people participate in the data entry and reporting for the project: project definition, requirements, task assignment, task status updates, defects, defect corrections, defect verifications, build and test schedules, ... the list goes on. A process is not a thing as much as a way of coordinating the team's efforts.

So how much time does the process require? If I offered you a process that required four hours a day from each developer, seven hours a day from requirements analysts, and nine hours a day from architects, would you buy my process? Certainly not! Involvement in the process takes people away from their real work, and putting such a heavy "load" on your teams diverts too much effort away from the business goal.

Managers commit two sins: failure to ask the question and failure to measure the load. They don't ask the salesmen about the workload on their teams. Instead, they worry about licensing costs and compatibility with existing processes. (Both important, and neither should be ignored, but their view is too limited. One must worry about the affect on the team.) Managers should research the true cost of the process, like any other purchase.

After implementing the process, managers should measure the load the process imposes on their teams. That is, they should not take the salesman's word for it, assuming the salesman was able to supply an estimate. An effective manager will measure the "load" several times, since the load may change as people become familiar with the process. The load may also change during the development cycle, with variations at different phases.

Not measuring is bad, but assuming that the process imposes no load is worse. Any process will have some load on your staff. Using a process and thinking that it is "free" is self-delusion and will cause distortions in your project schedule. Even with a light load of one hour per day, the assumption of zero load introduces an error of 12%. You think you have eight hours available from each person, when in fact you have only seven. That missing hour will eventually catch up with you.

It's said that the first step of management is measurement. If true, then the zeroth step of management is acknowledgment. You must acknowledge that a process has a cost, a non-zero cost, and that it can affect your team. Only after that can you start to measure the cost, and only then can you start to manage it.

The line doesn't move; the people in the line do

An engineer friend once commented, while we were waiting in line somewhere (it may be have been for fast food) that the line doesn't move; it's the people in the line who move.

The difference between the line and the people in line is a subtle one, yet obvious once it is brought to your attention. At 10:00, there is a line from the cash register out onto the floor. An hour later, the line will still be there, from the cash register out onto the floor. The line (a collection of people) has not moved -- it's still in the same store, starting at the same location. The fact that the people in the line have changed does not mean the line has moved. (If the line were to move, it would start in a different place or extend to another part of the shop.)

There is a similar subtle difference with bits and bit-built entities like songs and books and on-line magazines. We think that buying a song means buying bits, when in fact we're buying not a bunch of bits but a bunch of bits in a sequence. It's not the bits that make the song, it's the sequence of bits.

A sequence is not a tangible thing.

For a long time, sequences of bits were embedded in atoms. Books were sequences of characters (bits) embedded in ink on paper. Copying the sequence of bits meant collecting your own atoms to hold the copy of bits. In the Middle Ages, manuscripts were copied by hand and creating the new set of atoms was an expensive operation. The printing press and movable type made the copy operation less expensive, but there was still a significant cost for the atom "substrate".

In the twenty-first century, the cost of the atom substrate has dropped to a figure quite close to zero. The cost of the copy operation has also dropped to almost zero. the physical barriers to copies are gone. All that is left (to save the recording industry) is tradition, social norms, and law (and law enforcement). And while tradition and social norms may prevent folks born prior to 1980 from making copies, they don't seem to be holding back the later generations.

The RIAA, record labels, and other copyright holders want it both ways. They want bit sequences to be cheap to copy (for them) but hard to copy (for everyone else). They want bit sequences that are easily copied and distributed to consumers. Once the bits arrive in our in-box, or on our iPod, they wants the bits to magically transform into non-movable, non-copyable bits. They want bit sequences that are easy to move until they want them to be fixed in place. That's not how bits work.

In the end, physics wins. Wily E. Coyote can run off the cliff into air and hang there, defying gravity. But when he looks down, gravity kicks in.

Getting from here to there

Cloud computing is much like the early days of microcomputers. Not the early days of PCs (1981 to 1984) but the early days of microcomputers (1976 to 1980).

In the pre-PC era, there was no one vendor of hardware and software, and there was no one standard format for exchangeable media (also know as "floppy disks"). The de facto standard for an operating system was CP/M, but Apple had DOS and Radio Shack had TRS-DOS, and the UCSD p-System was lurking in corners.

Even with CP/M as a standard across the multitude of hardware platforms (Imsai, Sol, North Star, Heathkit, etc.) the floppy disk formats varied. These floppy disks were true floppies, in either 8 inch or 5.25 inch forms, with differences in track density, track count, and even the number of sides. There were single-sided disks and double-sided disks. There were 48-tpi (tracks per inch) disks and 96-tpi disks. Tracks were records in single density, double density, quad density, and extended density.

Moving data from one computer to another was an art, not a science, and most definitely not easy. It was all too common to have data on one system and desire it on another computer. Truly, these early computers were islands of automation.

Yet the desire to move data won out. We used null modem cables, bulletin board systems, and specially-written software to read "foreign" disks. (The internet existed at the time, but not for the likes of us hobbyists.)

Over time, we replaced the null modem cables and bulletin board systems with real networks. Today, we think nothing of moving data. Indeed, the cell phone business is the business of moving data!

The situation of cloud computing is similar. Clouds can hold data and applications, but we're not in a position to move data from one cloud to another. Well, not easily. One can dump the MySQL database to a text file, FTP it to a new site, and then import it into a new MySQL database; this is the modern-day equivalent of the null modem cables of yore.

Data exchange (for PCs) grew over a period of twenty years, from the early microcomputers, to the first IBM PC, to the releases of Netware, Windows for Workgroups, IBM OS/2, Windows NT, and eventually Windows Server. The big advances came when large players arrived on the scene: first IBM with an open hardware platform that allowed for network cards, and later Novell and Microsoft with closed software platforms that established standards (or used existing ones).

I expect that data exchange for cloud apps will follow a similar track. Unfortunately, I also expect that it will take a similar period of time.

Just how smart is your process?

Does your organization have a process? Specifically, does it have a process for the development of software?

The American mindset is one of process over skill. Define a good process and you don't need talented (that is, expensive) people. Instead of creative people, you can staff your teams with non-creative (that is, low wage) employees, and still get the same results. Or so the thinking goes.

The trend goes back to the scientific management movement of the early twentieth century.

For some tasks, the de-skilling of the workforce may make sense. Jobs that consist of repeated, well-defined steps, jobs with no unexpected factors, jobs that require no thought or creativity, can be handled by a process.

The creation of software is generally unrepeatable, has poorly-defined steps, has unexpected factors and events, and requires a great deal of thought. Yet many organizations (especially large organizations) attempt to define processes to make software development repeatable and predictable.

These organizations confuse software development with the project of software development. While the act of software development is unpredictable, a project for software development can be fit into a process. The project management tasks (status reports, personnel assignment, skills assessment, cost calculations, etc.) can be made routine. You most likely want them routine and standardized, to allow for meaningful comparison of one project to another.

Yet the core aspect of software development remains creative, and you cannot create a process for creative acts. (Well, you can create a process, and inflict it upon your people, but you will have little success with it.) Programming is an art more than science, and by definition an art is something outside of the realm of repeated processes.

Some organizations define a process that uses very specific requirements or design documents, removing all ambiguity and leaving the programming to low-skilled individuals. While this method appears to solve the "programming is an art" problem, it merely shifts the creative aspect to another group of individuals. This group (usually the "architects", "chief engineers", "tech leads", or "analysts") are doing the actual programming. (Perhaps not programming in FORTRAN or C#, but programming in English.) Shifting the creative work away from the coders introduces several problems, including the risk of poor run-time performance and the risk of specifying impossible solutions. Coders, the folks who wrangle the compiler, have the advantage of knowing that their solutions will either work or not work -- the computer tells them so. Architects and analysts who "program in English" have no such accurate and absolute feedback.

Successful management of software development consists not of reducing every task to a well-defined, repeatable set of steps, but of dividing tasks into the "repeatable" and "creative" groups, and managing both groups. For the repeatable tasks, use tools and techniques to automate the tasks and make them as friction-free as possible. For the creative tasks, provide well-defined goals and allow your teams to work on imaginative solutions.

The new new thing

The history of personal computers (or hobbyist computers, or microcomputers) has a few events that define new technologies which grant non-professionals (otherwise known as amateurs) the power to develop new, cutting edge applications. Such events are followed by a plethora of poorly-written, hard-to-maintain, and mediocre quality applications.

Previous enabling tools were Microsoft BASIC, dBase II, and Microsoft Visual Basic. Each of these packages "made programming easy". Consequently, lots of people created applications and unleashed them upon the world.

Microsoft BASIC is on the list due to its ease-of-use and its pervasiveness. In 1979, every computer for sale included a version of Microsoft BASIC (with the possible exception of the TRS-80 model II and the Heathkit H-8, H-11, and H-89 computers). Microsoft BASIC made lots of applications possible, and made it possible for just about anyone to create an application. And they did, and many of those applications that were poorly written impossible to maintain.

dBase II from Aston-Tate allowed the average Joe to create database applications, something possible in Microsoft BASIC only with lots of study and practice. dBase II used high-level commands to manipulate data, and lots of people wrote dBase II apps. The apps were poorly written and hard to maintain.

Microsoft's Visual Basic surpassed the earlier "MBASIC" and dBase II in popularity. It let anyone write apps for Windows. It was much easier than Microsoft's other Windows development tool, Visual C++. Microsoft scored a double win here, as apps in both Visual Basic and Visual C++ were poorly written and hard to maintain.

Languages and development environments since then have been designed for professional programmers and used by professional programmers. The "average Joe" does not pick up Perl and create apps.

The tide has shifted again, and now there is a new development tool, a new "new thing", that lets average people (that is, non-programmers) develop applications. It's called "salesforce.com".

salesforce.com is a cloud-based application platform that can build data-intensive applications. The name is somewhat deceptive, as the applications are not limited to sales. they can be anything, although the model leads one to the traditional view of a database with master/child relationships and transaction updates to a master file. I would not use it to create a word proccessor, a compiler, or a social network.

The important aspects are ease-of-use and availability. salesforce.com has both, with a simple, GUI-based development environment (and a web-based one at that!) and free access for individuals to experiment. The company even offers the "App Exchange", a place to sell (or give away) apps for the salesforce.com platform.

Be prepared for a lot of salesforce.com applications, many written by amateurs and poorly designed.