December 22, 2016

Code Inflation in /bin/true

  —Code mass is increasing even for simple things.

A friend provided a pointer to Code Inflation, published in IEEE Software (March/April 2015). It's an look at the growth of software and highlights this growth through the use of /bin/true and /bin/false over a twenty years or so. The statistics are staggering.

This article introduces some laws:
  • Software tends to grow over time whether or not a rationale need for this growth exists.
  • All nontrivial code contains defects.
  • The probability of a defect increases with code size.
And some wonderful advice: Instead of just adding more features to the next version of your code, resolve to simplify it.

This article references a paper by Rob Pike and Brian W. Kernighan, titled Program design in the UNIX environment which discusses the problems with the growth of cat in 1983. Pike and Kernighan discuss the style and use of UNIX:
... the UNIX system provided a new style of computing, a new way of thinking of how to attack a problem with a computer. This style was based on the use of tools: using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems, or by special-purpose, one-time programs.
This paper contains insight on the style and design of cat and points out how important identifying a single function for each tool is and how doing so leads to the creation of a computing environment that supports a level of flexibility and utility that are simply profound.

It is the single function and purpose of these tools which embodies their power and more importantly their inability to astonish during one's use of these tools. The inability to astonish here is important: the tools work as advertised with no surprise. That's a critically important quality. This leads to another important observation in this paper:
The key to problem-solving on the UNIX system is to identify the right primitive operations and to put them at the right place. UNIX programs tend to solve general problems rather than special cases. In a very loose sense, the programs are orthogonal, spanning the space of jobs to be done (although with a fair amount of overlap for reasons of history, convenience or efficiency). Functions are placed where they will do the most good: there shouldn’t be a pager in every program that produces output any more than there should be filename pattern matching in every program that uses filenames.
A simple read that takes a similar stance is a book by Kernighan and Plauger called Software Tools (and an updated edition titled Software Tools in Pascal). Software Tools provides unique insights into the same philosophy of functionality and combination that made UNIX work so well.

Some different perspectives on UNIX philosophy: Simplicity isn't simple.
comments powered by Disqus