Poetry in motion

Copyright and software are on a collision course. But perhaps in a way that is different from the current debates of piracy and fair use.

Copyright is an old notion. It goes back to the US constitution (1787) and the Statute of Anne (1709) and earlier, according to wikipedia.

Copyright makes the fundamental assumption of a fixed work. The US constitution limited copyright protection to books, maps, and charts. (Later acts extended copyright protection to phonograph recordings, painting, photographs, and software.)

In engineering, Statics is the study of non-moving things (such as buildings) and Dynamics is the study of moving objects (such as wheels on a car). Both are important. We want buildings to stand in place and cars to move.

In short, copyright law (and the mindset of copyright) is Statics, but software (and soon music, movies, videos, and e-books) is Dynamics.

The strict division between "fixed" and "moving" fails for software. Software doesn't move in the Newtonian sense -- it doesn't fly through the air or roll down inclines -- but it is not fixed in the same way a book is a fixed work. Once the ink is on the page and the pages bound, the book is a finished work. The same holds for maps, charts, phonograph recordings, photographs, and paintings.

Software is more fluid. Programs are never "finished"; there is always a change remaining, some defect to fix or feature to add.

Software changes. Suppliers issue updates. Microsoft issues monthly updates to Windows and its other products. Linux distros send out updates weekly. (To be fair, the updates are usually for a small fraction of the thousands of programs in a typical distro.)

Software is not a fixed work. If we assign a copyright term from the work's inception, when do we start counting for software? When does the copyright for Windows XP start (and by extension, when does it end)? We could pick an arbitrary date in early 2001 when Windows XP was initially released, but then what about Windows XP SP1? Should that receive its own copyright term?

We need some form of protection for software, some form of recognition of ownership and ownership rights. But the idea of copyright of a fixed work is a poor match for software. Instead of the firm block of stone we have a slushy pile of changing code.

Programming texts and literature

Stepping away from source code, let's look at the texts we use to learn programming.

There are the college texts, of course. But of late, I see very little that teaches general programming. I see many books on technology-specific programming ("C# Programming in .NET", and "Object-Oriented Programming in Java") and books on cross-training ("Java for C++ Programmers") but nothing for a average person (new to the field and not a student) to learn programming.

Perhaps the market is small. If you want to learn programming, you're going to be serious about it, not a hobbyist of the 1980s.

Perhaps there is no lingua franca and our multiple technologies are too specific for a general text. Programming in C# requires that one understand the C# concepts; programming in Java requires an understanding of Java details. The days of the universally available BASIC interpreter are gone.

Perhaps there is no constant view of programming. Each year sees advances, and every five years sees a complete turn-over in popular languages. We've gone from C to C++ to Java to C# to Perl to Python and now to Ruby (or Scala, or Haskell, or Erlang,...). Such a thought is disturbing; can we find no common concepts for programming in these different languages?

Whatever the reason, we have no standard texts for programming, no common body of knowledge. The Association for Computing Machinery has made an attempt to identify some canonical texts, but the group is too far from the mainstream to have much effect. (They probably won't like me saying such thing, either.)

Good writing is rare in our profession. The best books I have found come from O'Reilly, and even that is not a guarantee of literary quality.

Just what qualities do I desire? They fall into two catergories: writing and printing. I want books that are informative, comprehensive, and easy to read. I also want books with high quality printing: hard-cover editions with acid-free paper, elegant typesetting, comprehensive indexing, and easy-one the eyes typefaces.

In short, I want literature; works that are respected and also considered "a good read". I think that it is important that we have these works. Not just for people entering the field, but to develop our skills at composing, organizing, and presenting ideas. We need these skills, because composing, organizing, and presenting ideas is the objective of programming. We execute these skills for our programs; we should use them for our texts. To not exercise them in prose will let them atrophy, with the ultimate loss of them in our programs.

How much of your code is shipped?

Do you ship your code? If so, how much? Do you ship all of it, or only a fraction? The knee-jerk response is "of course we ship everything -- if we don't then we are inefficient".

On my current project, less than 100 percent of my code is shipped. I find that code that is not shipped falls into a few categories:

Early, wrong code Some code that I write is just plain wrong. It works for some cases but not all, and I eventually replace it.

Scaffolding Some of my code is not part of the product, but serves an auxiliary purpose such as testing, test frameworks, or diagnostics. For example, when the project requires that we generate output in a non-obvious form, I write code that converts the non-obvious form into a readable form. This code is not part of the final product yet it is very useful during development.

Proof of concept Sometimes I create small programs to verify a design. These programs are small, stand-alone utilities that have a single purpose. They prove that the design works, and let us start building the real product.

API exploration Sometimes APIs are documented poorly. A small program to wrap the API and and let me try various operations is easier to manage that a large program. The experience gives me knowledge and confidence in the API.

You might have other categories. But others or not, non-shipping code is sometimes useful. Don't worry too much about non-shipping code, but don't ignore it either. Use it to improve your overall efficiency.

Was Spinal Tap RIght?

Microsoft has a case of version number envy.

There is nothing funny about Version Number Envy, or "VNE". Many developers fall victim to this tyrannical disease every year. They suffer in silence with no one to listen. And there is no cure, not even a treatment.

From what I can tell, Microsoft believes that their products must have the highest version numbers. A given Microsoft product must have a higher version number than its competing products. I think this explains the odd version number skip of Internet Explorer (from 3 to 5) and Microsoft Office.

Contrast this with Microsoft products that have no immediate competition: they have simple, consistent version numbers. Microsoft Windows has advanced -- slowly -- from version 3.0 to 3.1 to 4.0 (Windows NT) to 5.0 (Windows 2000) to 6.0 (Windows XP) and now Windows 7. (Apparently even Microsoft wants to forget about Windows Vista.) Microsoft Internet Explorer, once it vanquished Netscape Navigator 4.0, has advanced linearly.

If you look at Microsoft Silverlight, you see an accelerated version numbering scheme. Silverlight is Microsoft's answer to Adobe Flash, and Flash is at version 10. Introduced in 2007, Microsoft Silverlight has joined the party late, and is therefore "behind" with lame version numbers such as 1.0 and 2.0. Yet Microsoft has revved Silverlight to version 4.0 in less than four years. They even re-numbered version 1.1 to version 2.0.

If I'm right, Microsoft will continue to rev Silverlight, until it surpasses Adobe Flash.

Also, if I am right, Microsoft will start to rev the version numbers for Windows. The popular Linux distributions of Ubuntu and SuSE are all at higher version numbers (Ubuntu at 10.04 and SuSE at -- gasp -- 11.3!) which puts Windows at an obvious (from the marketing perspective) disadvantage.

While version number envy is adjacent to Spinal Tap's obsession with having the loudest amplifiers ("ours go to eleven"), I think that Microsoft has a legitimate concern. I think that there is a psychological factor at work, with the general perception that a product with a higher version number is somehow better than a competing product.

So get ready for more Silverlight. Be prepared for new versions, with new features (some possibly hard to explain), and possibly some version number omissions (say, from 4.0 to 7.0) as Microsoft attempts to achieve parity with Adobe.

Web Servers Can Be Your Friends

During an informal discussion of system design with to former co-workers, they surprised me with their beliefs that web servers were, by design and in all cases, insecure and to be avoided.

This belief caught me by surprise.

I was proposing a system design that used service-oriented architecture in the form of web services. Such a system would allow for different services to be installed on a single server or multiple servers.

My colleagues liked the idea but flatly rejected the implementation, stating (with firm conviction) that web servers were not secure.

Some research into the issue confirms my idea that web servers are like any other type of program, and can be insecure (if administered poorly) but also can be secure (if administered properly). But I don't know that this research will convince my colleagues.

And that is the other thing that surprised me: my colleagues' attachment to an idea that is not true. That is the more frightening of the two surprises.

When learning a new technology, we often build a set of rules. Sometimes the rules are correct, and sometimes the rules change. Don't get caught with old rules!

Small is the new big, again

Computers have been getting smaller (yet more powerful) for decades. The early microcomputers (Apple II, Commodore PET, Radio Shack TRS-80) provided just enough processor and memory to do interesting things. They had less power than today's average non-smart cellphone, and much less than smartphones like the iPhone and Droid.

Since those days, microcomputers (now called PCs) have become more powerful, faster, cheaper, and smaller.

The trend for power has changed, though. We ran off of the curve of Moore's Law a few years ago, stopped by heat dissapation, etching resolution, and cosmic rays. Yet our thirst for power remains.

Cloud computing is the next big thing, and it uses computers, but it does not rely on increasing power. Or more specifically, it does not rely on increasing the power of a single device. Instead, cloud computing relies on the power of a collection of devices. (And allows for the addition or removal of devices.)

I find this point fascinating. We've stopped climbing the curve of Moore's Law, and we are now leveraging the network.

One observation is that the network is good enough to leverage. Our understanding of networking (hardware, software, and programming) is strong enough to support sophisticated configurations.

With a strong network technology, we can "ease off" on the push for powerful processors. We still need them, but we don't need then exclusively. In the past we pushed for faster processors, faster memory, and faster storage devices. Now we can re-balance our efforts and bring networks into the mix.

A second observation is that the cloud leverages not simply the network but the local network. (Yes, cloud apps live in the cloud and are accessed in a browser from anywhere, but the cloud-ish things occur on a local network.) It is the local network that has become "good enough"; the internet needs greater speeds and bandwidth.

Just as individuals and corporations adopted PCs and local networks, I predict that they will adopt cloud computing. The technology may not be ready for prime time, and we may see the emergence of a "killer app", but eventually the adoption will occur. If anything, it will be an expansion of the virtual desktop -- low-power PCs accessing virtual PCs on servers. With cheap (low-power) PCs in front of users and banks of cheap servers, we will be using cheap hardware at all levels of the infrastructure.

So small will be big, again.

Taking your lumps is good for you

What makes for good design? Many folks have written about it, and lots more have opinions.

For me, good design comes down to two operations: lumping and splitting. Lumping is the act of combining (or joining) items. Splitting is the act of separating them.

The two obvious domains that benefit from lumping and splitting are database design and object-oriented programming. A good database design brings closely-related fields into the same table, and pushes distinct concepts to separate tables. (There is more to good database design, but this is a good start.)

The same concepts hold for object-oriented design and programming. Keep similar items within a class and push distinct items into separate classes. Keep similar classes together in a namespace, and push different classes into different namespaces.

Lumping and splitting work for procedural programming too. If you've ever looked at a long function that does a lot (or even a small-ish one that works on multiple, disjoint data) and said "ugh" to yourself, then you know the results of improper lumping and splitting.

A high-level function in a system should work with high-level concepts. A function that deals with both high-level concepts and low-level concepts imposes a cognitive load upon the reader. The reader must jump from one level to another, keeping a stack of contexts in his head.

A well-written (or more accurately, a well-lumped and split) function will contain concepts for a single level. With a single level of concepts, the function is easier to comprehend.

Good programmers revise their programs, moving code to the proper place. They may start with tangled concepts, but they identify the different concepts and separate them, organizing the code. Not only do they eliminate duplicate code, but they push code to the proper level, creating methods, classes, namespaces, and libraries to hold the different sets of concepts.

Programming languages, over the years, have adopted syntax to help with such organization. C had limited scoping, C++ advanced coping with classes (and later namespaces), and Java and C# have had classes, packages, and namespaces from their inception. Good programmers take advantage of these structures to organize their code.

So if you are looking for good programmers, good designers, or good architects, look for people with lumping and splitting skills.

The hills are alive... with the price of music

Some time ago, I heard a radio program discuss the state of music distribution in the US. I don't remember the program, but it was probably on NPR.

On the program, a musician was bemoaning the state of the music market and the rampant piracy that infests our economy. They made a comment to the effect of "people have gotten used to music being free, and now they won't pay for it".

I disagree with that statement. Apple has shown a profitable business model with its iPods and iTunes products... and people pay for music.

I think that the artist (and the recording industry) has confused with "people paying what they think music is worth" and "people paying what the recording industry decides".

For years -- decades -- the recording industry decided the price of music. If you wanted the latest LP from Britney Spears, New Kids on the Block, Aerosmith, The Beatles, or Elvis Presley, you had to pay the price set at the local record store, which was a function of the price set by the RIAA. The recording industry had a monopoly on music. They were the place to go, and the only place to go. Even if you went to a different record store, you dealt with the RIAA.

With the internet and MP3 encoders, the music industry now has competition. People do not need to buy music at the price set by the RIAA. People can search the internet and find it for themselves.

Yet many people choose to buy their music through iTunes. Apple must be doing something right, to have success at selling music.

What the musicion on the radio program (and his fellow musicians, and the RIAA) fails to realize is that we now have a true market, and they cannot simply dictate the price. The days of arbitrarily and unilaterally setting a price for an album of songs (and selling the songs only as an album) are over. The market dictates the price, with buyers deciding to purchase from the legitimate sources or the illegitimate ones. The RIAA must compete with other sources.

Few companies like competition, except for the other guy. A monopoly is a nice, cozy arrangement and very profitable. But not always possible.

The Microsoft Mistakes That No One Talks About

There are two mistakes that Microsoft makes, and no one (at least no one that I know) has called them on.

The first mistake is an image problem. The general perception of Microsoft is that they are the Office corporation (that is, the company that produces Microsoft Office). This is the perception of the general public; if you stop a random person on the street and ask him or her what Microsoft produces, you will get the answer "Microsoft Office" (or "Word", "Excel", or possibly "Powerpoint"). This survey does not hold in the Seattle area or with subpopulations of programmers.

This image is a strength and a problem for Microsoft. It's a strength as it keeps Microsoft firmly ensconced in the corporate processing world. Business managers, purchasing managers, and architects know that Microsoft produces the standard products for office work.

It's a weakness in that it limits Microsoft. Apple has a different reputation -- one of the "shiny, spiffy consumer products company". Apple produces the iPhone, the iPod, the iPad, and oh yes the Macbook and a few other things.

Now I know that Microsoft makes lots more than MS Office. Their product line is broad and deep, with Windows, MS-SQL Server, IIS, the Xbox, and even mice and keyboards. But this is not about what I or the typical geek knows. This is about what John Q. Public knows. And he knows Office, and possibly Windows.

The second problem is within Microsoft. This problem is their fixation on Windows. Every product offered by Microsoft is tied to Windows in some way. It runs Windows, if possible. Everywhere you look in their product line is Windows. Windows, Windows, Windows... as far as the eye can see on the web site.

Microsoft's original goal was a PC on every desk and in every home. Some have added the phrase "and all of them running Microsoft software". That's not a bad goal. But I think the goal has changed, and now it is "a PC on every desk and in every home and all of them running Windows".

Windows is a desktop operating system and not suitable for all environments. Microsoft has made a go of it for the Xbox gaming console. It's had limited success with its home media server, phones, and Zune music player. One can argue that the products have failed due to poor marketing and poor design. I argue that the failure is, in part, due to Microsoft's insistence on Windows. Beyond alienating the hard-core Windows-haters, Microsoft is stuck with an architecture from the 1990s that flies poorly in 2010.

So my recommendation to Microsoft is to expand its vision. Go back to the idea of world domination, but drop the infatuation with Windows.

Does Microsoft Need Linux?

In my previous post I put forth the idea that Linux needs Microsoft to set hardware standards and drive PC hardware to a commodity. Now for the flip side: does Microsoft need Linux?

I'm sure that many folks at Microsoft wish that Linux would simply disappear. If it weren't for Linux (and its open source followers) the world would be a much simpler place and Microsoft would have a larger share of it.

The question is: Does Microsoft benefit from Linux? I think that it does, in a small way.

Linux keeps people focussed on the desktop model of computing. Desktop computing has been with us since 1981 and the IBM PC -- although some may argue that pre-PCs had some say in that . Let's say that it started, seriously, in 1977 with the Apple ][.

Desktop computing is different from the mainframe and minicomputer models. With desktop computing, each user has their own computer, and importantly for Microsoft, copies (and therefore licenses) of their software.

Several models have challenged the desktop. They include client/server, web apps, and smartphone apps. Client/server and web apps are similar to the mainframe model with a central server and remote users and only the central site paying for licenses. The smartphone app model has individual licenses but Apple has driven the cost of apps down to the $1.00 range, a far cry from the $500 license of PC applications.

Linux is clearly in the desktop application world. Linux may run the Droid smartphones but the mindspace for Linux is a competitor to Windows. It exists and it validates the desktop model. In this sense, Linux helps Windows.

Windows pays a price for Linux support of the desktop and server models. No small number of servers run Linux and Apache, not Windows and IIS. No small number of desktop PCs run Linux and OpenOffice and Firefox, not Windows and Microsoft Office and Internet Explorer. I suspect that the lost revenue outweighs the benefits of keeping people in the desktop fold.

Beyond that, I see little benefit to Microsoft, from Linux or from open source.

So the answer is no. Microsoft may benefit (somewhat) from Linux, but the cost outweighs the benefit. Microsoft does not need Linux and it would probably be better off without it.

Does Linux Need Microsoft?

Some folks in the open source movement like to bash Microsoft. Some folks in the Apple quarter like to bash Microsoft. Even some folks in the Microsoft quarter like to bash Microsoft.

But let us pause from our bashing and ask if we need Microsoft.

I think that we do.

Microsoft serves the Linux community by setting the hardware standard and driving computers to commodities. In the pre-cambrian era (before the introduction of the IBM PC), there were multiple platforms and CP/M set a tenous standard for disk I/O. (And only disk I/O. For terminals and printers, you were on your own. Networks were not even on the PC horizon.)

IBM set the hardware and software standard in 1981, with the IBM PC and its built-in BIOS. But IBM lost its leadership in 1987 with the introduction of the PS/2 line and Compaq's competing Deskpro 386 PCs. IBM's new line was too different and Compaq stepped up and set the hardware platform. Software, though, was set by Microsoft and its lock on PC-DOS and MS-DOS.

Microsoft gained power with Windows and set the software and hardware standard, something that it still does today. (The smartphones, netbooks, and slates are commercial successes, but they have not shifted PC architectures.)

As distasteful as it may be for Linux fans to admit, Linux owes its success to the standard, commodity hardware that Microsoft created. Linux needs Microsoft as its galactic center, something to revolve around. The PC standard lets Linux act as a parasite, taking advantage of a mostly uniform environment.

The commoditization of PCs, combined with higher requirements for new operating systems has provided a large supply of cheap, working, available equipment. I suspect that companies of every size have old PCs sitting in corners, unable to use the latest Windows and Microsoft applications. These PCs are the perfect place to experiment with Linux for little investment.

There are many reasons that Linux is successful. Reliability, availability of source code, multiple distributions for different needs, and a cute mascot have all helped. But it was Microsoft that made the environment which allows Linux to exist.

The next Perl may not be Perl

We've been using Perl for many years. The current version of Perl is 5. Perl six has been under development for over ten years. One is tempted to think that it may not arrive, that we may be stuck with Perl 5 for the rest of our programming careers.

I'm beginning to think that we already have the next version of Perl, available today. Not a preliminary copy, or a pre-beta version, but a fully-functional version of the next programming language. Two versions, actually.

The next version of Perl may be ... Python. Or perhaps Ruby.

These are both successful scripting languages. They are not Perl, yet they can do quite a lot. They have the performance, the necessary classes, and the support of the open source community.

The open source community may agree with me on this issue. At the latest OSCON, the sessions were weighted to Python (and PHP, oddly). Perl was a distant fourth behind Python, PHP, and Ruby.

It is possible that Perl has served its purpose in the tech world, demonstrating that scripting languages are feasible. Perhaps it is time that Perl steps aside and lets other languages extend the art.