27 Months

This content shows Simple View


The Virtues of Small Software

Essayist, poet and philosopher Ralph Waldo Emerson had this to say on the subject of beauty:

  • We ascribe beauty to that which is simple;
  • which has no superfluous parts;
  • which exactly answers its end;
  • which stands related to all things;
  • which is the mean of many extremes.

– The Conduct of Life, Chapter VIII, Beauty (via TinyApps blog)

Doug McIlroy, one of the founders of the Unix tradition, may well have drawn inspiration from Emerson when he summarized the Unix philosophy with the following three tenets: “Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.”

This philosophy placed a special emphasis on the use of a large number of software tools—small programs that could be strung together through a command line interpreter using pipes, as opposed to a single monolithic program that includes all of the same functionality.

An approach like this worked well because, in the late 1970’s and early 80’s, programmers had to work within the confines of relatively small and expensive resources. While difficult to conceive of today, 16KB of RAM was common and 64KB was considered expansive (I remember writing my first assembly program on the Commodore 64—I thought I was in heaven). Likewise, storage in the megabyte range was a luxury. Programmers created small software with tiny allocations of storage and RAM that ran on processors that were Lilliputian by today’s standards. Every byte and clock cycle counted, and thus a lot of work was done to make programs fit into available resources.

The rise of bloatware

Nowadays we have thousands of times the processing power, memory and storage yet, from the user’s perspective, software for the desktop, web and mobile seems to run slower than it should, or used to. We’ve been conditioned to accept long load times for applications, Ajax delays in Gmail, adware, automatic updates and the scourge of bundled third-party software.

Nathan Myhrvold, physicist and former CTO of Microsoft, once compared software to the physical properties of a gas for a keynote address in 1997. In a marriage of Moore’s Law and the Ideal Gas Law, he declared that “software always expands to fill whatever container it is stored in,” but its growth is “inevitably limited by the rate of increase in hardware speed.” So what happens when software hits the upper bounds of the hardware it’s contained in? Myhrvold’s response: “People buy new hardware because the software requires it.”

What Myhrvold succeeded in defining with his four Laws of Software, intentionally or not, is a Unified Theory of Bloatware. In one sense, his Third Law kept the PC business thriving by requiring bigger, faster hardware to run increasingly bloated software.

In a challenge to Moore’s Law comparing installed disk usage of Microsoft Office and Open Office (see above), we find that, “at this rate of growth, Microsoft Office Standard 2013 will be 5000MB, and the Microsoft Office Premium Platinum Plus 2013 edition (a larger edition than the Standard edition) will come on a set of Blu-ray discs.” The take-home message: “Microsoft Office Standard edition’s growth is more closely in step with maximum disk capacities.” Myhrvold was right, at least insofar as Microsoft Office is concerned.
One of the best attacks on bloatware ever, Thank you, Adobe Reader 9!, comes from Ben Hoyt, one of a trio of Kiwi brothers behind Brush Technology. His post is acerbic, hilarious and gives Adobe a well-deserved thrashing as a prime example of what’s wrong with contemporary software. Ben posits the question, Can Modern Software Be Snappy? and draws on some examples from coding for embedded devices and graphics programming. Both are great reads on this topic.

Incidentally, if you haven’t yet please do take Ben’s advice and replace Adobe Reader with Foxit’s PDF reader. You’ll not only save yourself disk space and headache, but avoid some rather nasty security vulnerabilities at the same time.

Small is the the next Big Thing
In an ironic twist, with the rising popularity of netbooks and rapid growth of mobile devices as the default computing platform, software is returning to a focus on “do one thing and do it well” within the resource constraints of these small devices. Moreover, as consumers and businesses alike tighten their budgets during the global economic downturn, extending the life of old hardware is becoming a necessity.

The good news for end-users is that alternatives to bloat do exist. If you want to go really small, the single best resource for apps that run will run on nearly any PC hardware has always been at TinyApps.org. Peruse the list, try a few out (none is bigger than 1.44 MB and many are contained in a single executable), link them up with some keyboard shortcuts and you’ll be working smarter and faster than ever. Trust me, it works.

For the engineer, designing small software that can run efficiently with limited resources was, until recently, a dying art. One of the best resources for programmers is the excellent (and free) book Small Memory by Charles Weir and James Noble. You can also listen to the authors interviewed on Software Engineering Radio.

I’m probably preaching to the choir here, but along with this book it’s worth considering some small software maxims for the engineer. Among the best are Eric Raymond’s design rules in The Art of Unix Programming, Mike Gancarz’s The UNIX Philosophy, and Rob Pike’s Notes on Programming in C. They’re summarized nicely here.

Included with the “small is beautiful” software design ethos is an emphasis on performance analysis, code profiling and refactoring. Too often, in my experience, this step is sacrificed under time pressure to deliver a product to market, yet it’s a crucial phase of any project. Bottlenecks often do occur in surprising places and speed hacks seldom work without solid metrics. It also never hurts to run an app through a processor emulator like QEMU to get a feel for how it will perform on older hardware.

Implications for African software
Citing the challenges brought by bad governance, poverty, low bandwidth, and some of the harshest environments and use-cases in the world, Erik Hersman noted that, “If it works in Africa, it will work anywhere.” If “do one thing and do it well” may be said to capture the philosophies of Unix and small software, Hersman’s declaration is the battle cry for a legion of cottage industry African software entrepreneurs.

By adopting the philosophy of small software, the developers crafting solutions on the African continent are in a unique position to reap opportunity from their environment. Witness highly specialized, targeted applications such as FrontlineSMS, MobilePress, Kerawa, Afrigator, Maneno, Zoopy, Ushahidi and countless others—all created by Africans and distributed online, often for free. One of the most interesting recent applications built for the developing world, FrontlineForms, is targeted specifically at low- to mid-level mobile devices.

These applications (and a lot of others I’ve surely overlooked) are at the forefront of what Samuel Dean called a “knock down, drag ‘em out renaissance…involving guerrilla apps, widgets, and many other software offerings that don’t happen to come from Microsoft or other gorilla-sized providers.”

The future of software is small. The implications for Africa, and the developing world at large, are huge.