Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

10 hard truths developers must learn to accept

Peter Wayner | April 3, 2012
On most days, programming is a rewarding experience, with no problem too challenging to solve. Perseverance, intuition, the right tool -- they all come together seamlessly to produce elegant, beautiful code.

When you start, you can grab the latest versions of the libraries and everything works for a week or two. Then version 1.0.2 of library A comes along, but it won't work with the latest version of library B because A's programmers have been stuck on the previous big release. Then the programmers working on C release some new feature that your boss really wants you to tap. Naturally it only works with version 1.0.2.

When houses and boats rot, they fall apart in one consistent way. When code rots, it falls apart in odd and complex ways. If you really want C, you have to give up B. If you choose B, you'll have to tell your boss that C isn't a real option.

This example used only three libraries. Real projects use a dozen or more, and the problems grow exponentially. To make matters worse, the rot doesn't always present itself immediately. Sometimes it seems like the problem is only in one unimportant corner that can be coded around. But often this tiny incompatibility festers and the termites eat their way through everything until it all collapses.

The presence of bitrot is made all the more amazing by the fact that computer code doesn't wear out. There are no moving parts, no friction, no oxidation, and no carbon chains acting as bait for microbes. Our code is an eternal statement that should be just as good in 100 years as it was on the day it was written. Yet it isn't.

The only bright spots are the emulators that allow us to run that old Commodore 64 or Atari code again and again. They're wonderful museums that keep code running forever -- as long as you fight the bitrot in the emulator.

Developer hard truth No. 10: The walled garden will flourish

For all the talk about the importance of openness, there's more and more evidence that only a small part of the marketplace wants it. To make things worse, they're often not as willing to pay for the extra privilege. The free software advocates want free as in speech and free as in beer. Few are willing to pay much for it.

That may be why the biggest adopters of Linux and BSD come wrapped in proprietary code. Devices like TiVo may have Linux buried inside, but the interface that makes them great isn't open. The same goes for the Mac.

The companies that ship Linux boxes, however, have trouble competing against Windows boxes. Why pay about the same price for Linux when you can buy a Windows machine and install Linux alongside?

Walled gardens flourish when people will pay more for what's inside, and we're seeing more and more examples of cases when the people will pay the price of admission. Mac laptops may cost two to three times as much as a commodity PC, yet the stores are packed to the limit imposed by the fire code.


Previous Page  1  2  3  4  5  6  Next Page 

Sign up for Computerworld eNewsletters.