Coding Horror

Michael Braude decries the popularity of web programming:

The reason most people want to program for the web is that they're not smart enough to do anything else. They don't understand compilers, concurrency, 3D or class inheritance. They haven't got a clue why I'd use an interface or an abstract class. They don't understand: virtual methods, pointers, references, garbage collection, finalizers, pass-by-reference vs. pass-by-value, virtual C++ destructors, or the differences between C# structs and classes. They also know nothing about process. Waterfall? Spiral? Agile? Forget it. They've never seen a requirements document, they've never written a design document, they've never drawn a UML diagram, and they haven't even heard of a sequence diagram.

But they do know a few things: they know how to throw an ASP.NET webpage together, send some (poorly done) SQL down into a database, fill a dataset, and render a grid control. This much they've figured out. And the chances are good it didn't take them long to figure it out.

So forgive me for being smarmy and offensive, but I have no interest in being a 'web guy'. And there are two reasons for this. First, it's not a challenging medium for me. And second, because the vast majority of Internet companies are filled with bad engineers - precisely because you don't need to know complicated things to be a web developer. As far as I'm concerned, the Internet is responsible for a collective dumbing down of our intelligence. You just don't have to be that smart to throw up a webpage.

I really hope everybody's wrong and everything doesn't "move to the web." Because if it does, one day I will either have to reluctantly join this boring movement, or I'll have to find another profession.

Let's put aside, for the moment, the absurd argument that web development is not challenging, and that it attracts sub-par software developers. Even if that was true, it's irrelevant.

I hate to have to be the one to break the bad news to Michael, but for an increasingly large percentage of users, the desktop application is already dead. Most desktop applications typical users need have been replaced by web applications for years now. And more are replaced every day, as web browsers evolve to become more robust, more capable, more powerful.

You hope everything doesn't "move to the web"? Wake the hell up! It's already happened!

Any student of computing history will tell you that the dominance of web applications is exactly what the principle of least power predicts:

Computer Science spent the last forty years making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it. If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. The only way to find out what a Java applet means is to set it running in front of a person.

The web is the very embodiment of doing the stupidestsimplest thing that could possibly work. If that scares you -- if that's disturbing to you -- then I humbly submit that you have no business being a programmer.

Should all applications be web applications? Of course not. There will continue to be important exceptions and classes of software that have nothing to do with the web. But these are minority and specialty applications. Important niches, to be sure, but niches nonetheless.

If you want your software to be experienced by as many users as possible, there is absolutely no better route than a web app. The web is the most efficient, most pervasive, most immediate distribution network for software ever created. Any user with an internet connection and a browser, anywhere in the world, is two clicks away from interacting with the software you wrote. The audience and reach of even the crappiest web application is astonishing, and getting larger every day. That's why I coined Atwood's Law.

Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.

Writing Photoshop, Word, or Excel in JavaScript makes zero engineering sense, but it's inevitable. It will happen. In fact, it's already happening. Just look around you.

As a software developer, I am happiest writing software that gets used. What's the point of all this craftsmanship if your software ends up locked away in a binary executable, which has to be purchased and licensed and shipped and downloaded and installed and maintained and upgraded? With all those old, traditional barriers between programmers and users, it's a wonder the software industry managed to exist at all. But in the brave new world of web applications, those limitations fall away. There are no boundaries. Software can be everywhere.

Web programming is far from perfect. It's downright kludgy. It's true that any J. Random Coder can plop out a terrible web application, and 99% of web applications are absolute crap. But this also means the truly brilliant programmers are now getting their code in front of hundreds, thousands, maybe even millions of users that they would have had absolutely no hope of reaching pre-web. There's nothing sadder, for my money, than code that dies unknown and unloved. Recasting software into web applications empowers programmers to get their software in front of someone, somewhere. Even if it sucks.

If the audience and craftsmanship argument isn't enough to convince you, consider the business angle.

You're doing a web app, right? This isn't the 1980s. Your crummy, half-assed web app will still be more successful than your competitor's most polished software application.

Pretty soon, all programming will be web programming. If you don't think that's a cause for celebration for the average working programmer, then maybe you should find another profession.

Will Work for Praise: The Web's Free-Labor Economy describes how many of today's websites are built by the users themselves:

It's dawn at a Los Angeles apartment overlooking the Hollywood Hills. Laura Sweet, an advertising creative director in her early 40s, sits at a computer and begins to surf the Net. She searches intently, unearthing such bizarre treasures for sale as necklaces for trees and tattoo-covered pigs. As usual, she posts them on a shopping site called ThisNext.com. Asked why in the world she spends so many hours each week working for free, she answers: "It's a labor of love."

This raises some disturbing parallels. Are users being turned into digital sharecroppers?

MySpace, Facebook, and many other businesses have realized that they can give away the tools of production but maintain ownership over the resulting products. One of the fundamental economic characteristics of Web 2.0 is the distribution of production into the hands of the many and the concentration of the economic rewards into the hands of the few. It's a sharecropping system, but the sharecroppers are generally happy because their interest lies in self-expression or socializing, not in making money, and, besides, the economic value of each of their individual contributions is trivial.

It's only by aggregating those contributions on a massive scale - on a web scale - that the business becomes lucrative.

In essence, any website where user generated content is the website, that is also a for-profit business (not a non-profit organization, ala Wikipedia) — is effectively turning their users into digital sharecroppers. Digital sharecroppers typically get nothing in return for the content they've provided, and often give up all rights to what they've created. At least a real world sharecropper would get to keep a percentage of the crops produced on the land.

The tone of the relationship between virtual land owner and so-called digital sharecroppers is critical. When crowdsourcing goes sour, there can be mass revolts.

Wikia is a for-profit corporation launched by several high level people involved with Wikipedia, such as co-founder Jimmy Wales. Wikipedia has no significant financial connection to Wikia. But an enormous publicity benefit accrues to Wikia due to Wikipedia's fame: $14m of venture capital has been invested in Wikia. Its business model is to have a "community" (writers who work for free) to build a wiki website about a topic, and then to sell advertising on those pages. In short, Wikia hosts sites in return for all the ad revenues.

At the start of June, Wikia's CEO announced that many changes would be made to the appearance of sites, mainly to have more advertising and for the ads to be more prominent. As Wikia's community development manager put it: "We have to change things in order to make Wikia financially stable. Unfortunately, Google ads in the footer pay pennies a click, and nobody clicks". He went on to explain that ads paying based on view count were needed. And that type of advertiser wants their ad to be displayed where viewers are sure to see it, such as within an article, near the top.

In reaction, various content creators made it clear they understood the needs of the company and had no objection to advertising per se. But putting ads inside content risked changing their material from articles into decorated billboards. The conflict between management and (unpaid) labour became acrimonious. There were declarations such as: "If Wikia does not resolve this situation to our satisfaction, then we will leave, taking our content, our communities' inward links, our established service marks and our fellow editors with us."

This is a topic that I've spent a great deal of time thinking about, because we happen to run a site chock full of user generated questions and answers. The last thing I want to do is exploit Stack Overflow users for corporate gain, even accidentally. That's horrible.

So if you spend a lot of time creating content on someone else's website — whether it's Stack Overflow, or anywhere else on the internet — you should be asking yourself some tough questions:

• What do you get out of the time and effort you've invested in this website? Personally? Professionally? Tangibly? Intangibly?
• Is your content attributed to you, or is it part of a communal pool?
• What rights do you have for the content you've contributed?
• Can your contributions be revoked, deleted, or permanently taken offline without your consent?
• Can you download or archive your contributions?
• Are you comfortable with the business model and goals of the website you're contributing to, and thus directly furthering?

There should always be a healthy, reciprocal relationship between you and any websites you're contributing to. I like to think that Stack Overflow gives back to the community as much as it absorbs — both in the form of Creative Commons shared ownership of the underlying data, and the strong emphasis on showing off the individual skills and knowledge of your fellow programmers.

Ultimately, you have to decide which is more important — building your own brand, or building the brand of the website you're contributing to? While these two concepts are not necessarily opposed, I strongly urge everyone reading this to err on the side of building your own brand whenever possible. Websites tend to come and go; the only sensible long term strategy is to invest in something that's guaranteed to be around for the rest of your life: you.

But I guess I'm biased.

I'd like to talk to you about ducts. Wait a minute. Strike that. I meant COBOL. The Common Business Oriented Language is celebrating its fiftieth anniversary as the language that is everywhere and nowhere at once:

As a result, today COBOL is everywhere, yet is largely unheard of among the millions of people who interact with it on a daily basis. Its reach is so pervasive that it is almost unthinkable that the average person could go a day without it. Whether using an ATM, stopping at traffic lights or purchasing a product online, the vast majority of us will use COBOL in one form or another as part of our daily existence.

The statistics that surround COBOL attest to its huge influence upon the business world. There are over 220 billion lines of COBOL in existence, a figure which equates to around 80% of the world's actively used code. There are estimated to be over a million COBOL programmers in the world today. Most impressive perhaps, is that 200 times as many COBOL transactions take place each day than Google searches - a figure which puts the influence of Web 2.0 into stark perspective.

Every year, COBOL systems are responsible for transporting up to 72,000 shipping containers, caring for 60 million patients, processing 80% of point-of-sales transactions and connecting 500 million mobile phone users. COBOL manages our train timetables, air traffic control systems, holiday bookings and supermarket stock controls. And the list could go on.

I have a hard time reconciling this data point with the fact that I have never, in my entire so-called "professional" programming career, met anyone who was actively writing COBOL code. That probably says more about my isolation as a programmer than anything else, but still. I find the whole situation a bit perplexing. If these 220 billion lines of COBOL code are truly running out there somewhere, where are all the COBOL programmers? Did they write software systems so perfect, so bug-free, that all these billions of lines of code are somehow maintaining themselves without the need for legions and armies of COBOL programmers, decades later?

If so, that's a mighty impressive feat.

And if COBOL is so pervasive, why is it number one in this list of dead (or dying) computer skills compiled in 2007?

Y2k was like a second gold rush for Cobol programmers who were seeing dwindling need for their skills. But six-and-a-half years later, there's no savior in sight for this fading language. At the same time, while there's little curriculum coverage anymore at universities teaching computer science, "when you talk to practitioners, they'll say there are applications in thousands of organizations that have to be maintained," says Heikki Topi, chair of computer information services at Bentley College in Waltham, Mass., and a member of the education board for the Association for Computing Machinery.

When you dig in and read about some of these real world COBOL systems, you can get a glimpse of the sort of difficulties they're facing.

Read says Columbia Insurance's policy management and claims processing software is 20 years old and has 1 million lines of COBOL code with some 3,000 modifications layered on over the years. "Despite everyone pronouncing Cobol dead for a couple of decades, it's still around," he says. "We continue to enhance the base system. It's still green-screen, if you can believe that."

Read says getting younger workers to take on Cobol chores is a "real challenge, because that's not where technology is today." He simply tells them they must do some Cobol work, promising a switch to other things at the earliest opportunity.

Remember how the common language runtime of .NET promised rich support for a plethora of different languages -- but none of that ever mattered because everyone pretty much just uses C# anyway? Well, that CLR didn't go to waste, because it is possible to write code in COBOL.NET.

See for yourself.

private void button1_Click(object sender, System.EventArgs e)
{
button1.Text = "Call COBOL";
}

That was C#, of course. Here's the COBOL.NET version of same:

METHOD-ID. button1_Click PRIVATE.
DATA DIVISION.
LINKAGE SECTION.
01 sender OBJECT REFERENCE CLASS-OBJECT.
01 e OBJECT REFERENCE CLASS-EVENTARGS.
PROCEDURE DIVISION USING BY VALUE sender e.
SET PROP-TEXT OF button1 TO "Call COBOL".
END METHOD button1_Click.

Is there anything I could write here that the above code doesn't make abundantly clear?

COBOL: so vibrantly alive, yet … so very, very dead.

One of the side effects of using the iPhone App store so much is that it's started to fundamentally alter my perception of software pricing. So many excellent iPhone applications are either free, or no more than a few bucks at most. That's below the threshold of impulse purchase and squarely in no-brainer territory for anything decent that I happen to be interested in.

But applications that cost $5 or more? Outrageous! Highway robbery!

This is all very strange, as a guy who is used to spending at least $30 for software of any consequence whatsoever. I love supporting my fellow software developers with my wallet, and the iPhone App Store has never made that easier.

While there's an odd aspect of race to the bottom that I'm not sure is entirely healthy for the iPhone app ecosystem, the idea that software should be priced low enough to pass the average user's "why not" threshold is a powerful one.

What I think isn't well understood here is that low prices can be a force multiplier all out of proportion to the absolute reduction in price. Valve software has been aggressively experimenting in this area; consider the example of the game Left 4 Dead:

Valve co-founder Gabe Newell announced during a DICE keynote today that last weekend's half-price sale of Left 4 Dead resulted in a 3000% increase in sales of the game, posting overall sales (in dollar amount) that beat the title's original launch performance.

It's sobering to think that cutting the price in half, months later, made more money for Valve in total than launching the game at its original $49.95 price point. (And, incidentally, that's the price I paid for it. No worries, I got my fifty bucks worth of gameplay out of this excellent game months ago.)

The experiments didn't end there. Observe the utterly non-linear scale at work as the price of software is experimentally reduced even further on their Steam network:

The massive Steam holiday sale was also a big win for Valve and its partners. The following holiday sales data was released, showing the sales breakdown organized by price reduction:

• 10% sale = 35% increase in sales (real dollars, not units shipped)
• 25% sale = 245% increase in sales
• 50% sale = 320% increase in sales
• 75% sale = 1470% increase in sales

Note that these are total dollar sale amounts! Let's use some fake numbers to illustrate how dramatic the difference really is. Let's say our hypothetical game costs $40, and we sold 100 copies of it at that price.

If this pattern Valve documented holds true, and if my experience on the iPhone App store is any indication, we've been doing software pricing completely wrong. At least for digitally distributed software, anyway.

In particular, I've always felt that Microsoft has priced their operating system upgrades far, far too high -- and would have sold a ton more licenses if they had sold them at the "heck, why not?" level. For example, take a look at these upgrade options:

Putting aside schoolyard OS rivalries for a moment, which one of these would you be more likely to buy? I realize this isn't entirely a fair comparison, so if $29 seems as bonkers to you as an application for 99 cents -- which I'd argue is much less crazy than it sounds -- then fine. Say the Windows 7 upgrade price was a more rational $49, or $69. I'm sure the thought of that drives the Redmond consumer surplus capturing marketing weasels apoplectic. But the Valve data -- and my own gut intuition -- leads me to believe that they'd actually make more money if they priced their software at the "why not?" level.

I'm not saying these pricing rules should apply to every market and every type of software in the world. But for software sold in high volumes to a large audience, I believe they might. At the very least, if you sell software, you might consider experimenting with pricing, as Valve has. You could be pleasantly surprised.

I love buying software, and I know I buy a heck of a lot more of it when it's priced right. So why not?

As programmers, we regularly work with text encodings. But there's another sort of encoding at work here, one we process so often and so rapidly that it's invisible to us, and we forget about it. I'm talking about visual encoding -- translating the visual glyphs of the alphabet you're reading right now. The alphabet is no different than any other optical machine readable input, except the machines are us.

But how efficient is the alphabet at encoding information on a page? Consider some of the alternatives -- different visual representations of data you could print on a page, or display on a monitor:

5081 punch card
up to 80 alphanumeric characters

Maxicode
up to 93 alphanumeric characters

Data Matrix
up to 2,335 alphanumeric characters

QR Code
up to 4,296 alphanumeric characters

Aztec Code
up to 3,067 alphanumeric characters

High Capacity Color Barcode
varies by # of color and density; up to 3,500 characters per square inch

Printed page
about 10,000 characters per page

Paper the way we typically use it is criminally inefficient. It has a ton of wasted data storage space. That's where programs like PaperBack come in:

PaperBack is a free application that allows you to back up your precious files on ordinary paper in the form of oversized bitmaps. If you have a good laser printer with the 600 dpi resolution, you can save up to 500,000 bytes of uncompressed data on a single sheet.

You may ask - why? Why, for heaven's sake, do I need to make paper backups, if there are so many alternative possibilities like CD-R's, DVD±R's, memory sticks, flash cards, hard disks, streaming tapes, ZIP drives, network storage, magneto-optical cartridges, and even 8-inch double-sided floppy disks formatted for DEC PDP-11? The answer is simple: you don't. However, by looking on CD or magnetic tape, you are not able to tell whether your data is readable or not. You must insert your medium into the drive, if you even have one, and try to read it.

Paper is different. Do you remember punched cards? For years, cards were the main storage medium for the source code. I agree that 100K+ programs were... inconvenient, but hey, only real programmers dared to write applications that large. And used cards were good as notepads, too. Punched tapes were also common. And even the most weird encodings, like CDC or EBCDIC, were readable by humans (I mean, by real programmers).

Of course, bitmaps produced by PaperBack are also human-readable (with the small help of any decent microscope). I'm joking. What you need is a scanner attached to your PC.

PaperBack, like many of the other visual encodings listed above, includes provisions for:

• compression -- to increase the amount of data stored in a given area.
• redundancy -- in case part of the image becomes damaged or is otherwise unreadable.
• encryption -- to prevent the image from being readable by anyone except the intended recipient.

Sure, it's still paper, but the digital "alphabet" you're putting on that paper is a far more sophisticated way to store the underlying data than traditional ASCII text.

This may all seem a bit fanciful, since the alphabet is about all us poor human machines can reasonably deal with, at least not without the assistance of a computer and scanner. But there is at least one legitimate use for this stuff, the trusted paper key. There's even software for this purpose, PaperKey:

The goal with paper is not secure storage. There are countless ways to store something securely. A paper backup also isn't a replacement for the usual machine readable (tape, CD-R, DVD-R, etc) backups, but rather as an if-all-else-fails method of restoring a key. Most of the storage media in use today do not have particularly good long-term (measured in years to decades) retention of data. If and when the CD-R and/or tape cassette and/or USB key and/or hard drive the secret key is stored on becomes unusable, the paper copy can be used to restore the secret key.

For paper, on the other hand, to claim it will last for 100 years is not even vaguely impressive. High-quality paper with good ink regularly lasts many hundreds of years even under less than optimal conditions.

Another bonus is that ink on paper is readable by humans. Not all backup methods will be readable 50 years later, so even if you have the backup, you can't easily buy a drive to read it. I doubt this will happen anytime soon with CD-R as there are just so many of them out there, but the storage industry is littered with old now-dead ways of storing data.

Computer encoding formats and data storage schemes come and go. This is why so much archival material survives best in the simplest possible formats, like unadorned ASCII. Depending on what your goals are, a combination of simple digital encoding and the good old boring, reliable, really really old school technology of physical paper can still make sense.