Sort By:

Sanity vs. Invisible Markings:
Tabs vs. spaces

Invisible and near-invisible markings bring us to the human part of the problem?not that code editor authors aren’t human, but most of us will not write new editors, though all of us will use editors. As we all know, once upon a time computers had small memories and the difference between a tab, which is a single byte, and a corresponding number of spaces (8) could be a significant difference between the size of source code stored on a precious disk, and also transferred, over whatever primitive and slow bus, from storage into memory.

by George Neville-Neil | July 26, 2020


The Obscene Coupling Known as Spaghetti Code:
Teach your junior programmers how to read code

Since you both are working on the same code base, you also have ample opportunity for leadership by showing this person how you code. You must do this carefully or the junior programmer will think you’re pulling rank, but, with a bit of gentle show and tell, you can get your Padawan to see what you’re driving at. This human interaction is often difficult for those of us who prefer to spend our days with seemingly logical machines.

by George Neville-Neil | August 7, 2018


Metaphors We Compute By:
Code is a story that explains how to solve a particular problem.

Programmers must be able to tell a story with their code, explaining how they solved a particular problem. Like writers, programmers must know their metaphors. Many metaphors will be able to explain a concept, but you must have enough skill to choose the right one that’s able to convey your ideas to future programmers who will read the code. Thus, you cannot use every metaphor you know. You must master the art of metaphor selection, of meaning amplification. You must know when to add and when to subtract. You will learn to revise and rewrite code as a writer does. Once there’s nothing else to add or remove, you have finished your work.

by Alvaro Videla | July 24, 2017


The Unholy Trinity of Software Development:
Tests, documentation, and code

Questions like this bring to mind the fact that source code, documentation, and testing are the unholy trinity of software development, although many organizations like to see them as separate entities. It is interesting that while many groups pay lip service to "test-driven development," they do not include documentation in TDD.

by George Neville-Neil | October 31, 2016


Code Hoarding:
Committing to commits, and the beauty of summarizing graphs

Dear KV, Why are so many useful features of open-source projects hidden under obscure configuration options that mean they’ll get little or no use? Is this just typically poor documentation and promotion, or is there something that makes these developers hide their code? It’s not as if the code seems broken. When I turned these features on in some recent code I came across, the system remained stable under test and in production. I feel that code should either be used or removed from the system. If the code is in a source-code repository, then it’s not really lost, but it’s also not cluttering the rest of the system.

by George Neville-Neil | February 23, 2016


Lazarus Code:
No one expects the Spanish Acquisition.

I’ve been asked to look into the possibility of taking a 15-year-old piece of open-source software and updating it to work on a current system used by my company. The code itself doesn’t seem to be too bad, at least no worse than the code I’m used to reading, but I suspect it might be easier to write a new version from scratch than to try to understand code that I didn’t write and which no one has actively maintained for several years.

by George Neville-Neil | May 6, 2015


Code Abuse:
One programmer’s extension is another programmer’s abuse.

During some recent downtime at work, I’ve been cleaning up a set of libraries, removing dead code, updating documentation blocks, and fixing minor bugs that have been annoying but not critical. This bit of code spelunking has revealed how some of the libraries have been not only used, but also abused. The fact that everyone and their sister use the timing library for just about any event they can think of isn’t so bad, as it is a library that’s meant to call out to code periodically (although some of the events seem as if they don’t need to be events at all).

by George Neville-Neil | December 5, 2012


Can More Code Mean Fewer Bugs?:
The bytes you save today may bite you tomorrow

Dear One, You almost had me with your appeal to simplicity, that having a single line with system() on it reduces the potential for bugs. Almost, but not quite.

by George V. Neville-Neil | August 8, 2012


A Nice Piece of Code:
Colorful metaphors and properly reusing functions

In the last installment of Kode Vicious (A System is not a Product, ACM Queue 10 (4), April 2012), I mentioned that I had recently read two pieces of code that had actually lowered, rather than raised, my blood pressure. As promised, this edition’s KV covers that second piece of code.

by George Neville-Neil | June 5, 2012


My Compiler Does Not Understand Me:
Until our programming languages catch up, code will be full of horrors.

Only lately have a lot of smart people found audiences for making sound points about what and how we code. Various colleagues have been beating drums and heads together for ages trying to make certain that wise insights about programming stick to neurons. Articles on coding style in this and other publications have provided further examples of such advocacy.

by Poul-Henning Kamp | May 21, 2012


A System is not a Product:
Stopping to smell the code before wasting time reentering configuration data

Every once in a while, I come across a piece of good code and like to take a moment to recognize this fact, if only to keep my blood pressure low before my yearly medical checkup. The first such piece of code to catch my eye was clocksource.h in Linux. Linux interfaces with hardware clocks, such as the crystal on a motherboard, through a set of structures that are put together like a set of Russian dolls.

by George V. Neville-Neil | April 12, 2012


The Hyperdimensional Tar Pit:
Make a guess, double the number, and then move to the next larger unit of time.

When I started in computing more than a quarter of a century ago, a kind elder colleague gave me a rule of thumb for estimating when I would have finished a task properly: make a guess, double the number, and then move to the next larger unit of time. This rule scales tasks in a very interesting way: a one-minute task explodes by a factor of 120 to take two hours. A one-hour job explodes by "only" a factor 48 to take two days, while a one-day job grows by a factor of 14 to take two weeks.

by Poul-Henning Kamp | January 23, 2012


Code Rototilling:
KV hates unnecessary work.

Dear KV, Whenever a certain programmer I work with needs to add a variable to a function and the name collides with a previously used name, he changes all of the previous instances to a new different name so that he can reuse the name himself. This causes his diffs to be far larger than they need to be and annoys the hell out of me. Whenever I challenge him on this, he says that the old usage was wrong, anyway, but I think that’s just him making an excuse.

by George Neville-Neil | December 14, 2011


Coding Guidelines: Finding the Art in the Science:
What separates good code from great code?

Computer science is both a science and an art. Its scientific aspects range from the theory of computation and algorithmic studies to code design and program architecture. Yet, when it comes time for implementation, there is a combination of artistic flare, nuanced style, and technical prowess that separates good code from great code.

by Robert Green, Henry Ledgard | November 2, 2011


Facing an Uncertain Past:
Excuses, excuses, excuses!

Using my favorite Greek passive-present-neuter participle (I trust you have one, too), I offer a dramatic prolegomenon to this overdue column. To wit, an apology and an explanation for its tardiness. (You’ll notice the potentially unending recursion, since both column and excuses are late.) The apology is easy: we Brits just say "Jolly sorry, actually," and project a pained sincerity, whether we mean it or not.

by Stan Kelly-Bootle | September 24, 2010


Painting the Bike Shed:
A sure-fire technique for ending pointless coding debates

Last week one of our newer engineers checked in a short program to help in debugging problems in the code that we’re developing. Even though this was a test program, several people read the code and then commented on the changes they wanted to see. The code didn’t have any major problems, but it seemed to generate a lot of e-mail for what was being checked in. Eventually the comments in the thread were longer than the program itself. At some point in the thread the programmer who submitted the code said, "Look, I’ve checked in the code; you can paint the bike shed any color you want now," and then refused to make any more changes to the code.

by George V. Neville-Neil | June 25, 2009


The Flaws of Nature:
And the perils of indecision. The latest musings of Stan Kelly-Bootle.

Multicolumnar ideas had been lurking like Greek temples in my so-called mind as 2008 came to an end. There are so many annual journalistic clichés available, looking back at all our past-years’ mistakes and resolving never to repeat them in 2009. One annoyance that I must get off my chest here and now: Can we ban such empty constructions as "X is much worse than you may think"? Or "Y is much simpler than many suppose"? We may never have thought of X one way or the other, or made suppositions about the ease of Y, yet we tend to nod and move on as though some meaningful proposition has been asserted; and, worse, that some judgment has been validated beyond dispute.

by Stan Kelly-Bootle | February 23, 2009


Code Spelunking Redux:
Is this subject important enough to warrant two articles in five years? I believe it is.

It has been five years since I first wrote about code spelunking, and though systems continue to grow in size and scope, the tools we use to understand those systems are not growing at the same rate. In fact, I believe we are steadily losing ground. So why should we go over the same ground again? Is this subject important enough to warrant two articles in five years? I believe it is.

by George V. Neville-Neil | January 8, 2009


Get Real about Realtime:
Dear KV, I’m working on a networked system that has become very sensitive to timing issues.

I’m working on a networked system that has become very sensitive to timing issues. When the system was first developed the bandwidth requirements were well within the tolerance of off-the-shelf hardware and software, but in the past three years things have changed. The data stream has remained the same but now the system is being called on to react more quickly to events as they arrive. The system is written in C++ and runs on top of Linux. In a recent project meeting I suggested that the quickest route to decreasing latency was to move to a realtime version of Linux, since realtime operating systems are designed to provide the lowest-latency services to applications.

by George Neville-Neil | December 4, 2008


Affine Romance:
Buyer (and seller) beware

There’s a British idiom, “Suck it and see,” the epitome of skepticism, which despite its coarse brevity could well replace whole libraries of posh philosophic bigtalk about the fabric of reality. A less aggressive version is “Show me, I’m from Missouri,” which requires the proper Southern Mizoorah drawl for maximum impact. Wherever you’re from, the message is one of eternal vigilance in the face of fancy claims.

by Stan Kelly-Bootle | October 24, 2008


Beautiful Code Exists, if You Know Where to Look:
A koder with attitude, KV answers your questions. Miss Manners he ain’t.

I’ve been reading your rants for a while now and I can’t help asking, is there any code you do like? You always seem so negative; I really wonder if you actually believe the world of programming is such an ugly place or if there is, somewhere, some happy place that you go to but never tell your readers about.

by George Neville-Neil | October 24, 2008


Only Code Has Value?:
Even the best-written code can’t reveal why it’s doing what it’s doing.

A recent conversation about development methodologies turned to the relative value of various artifacts produced during the development process, and the person I was talking with said: the code has "always been the only artifact that matters. It’s just that we’re only now coming to recognize that." My reaction to this, not expressed at that time, was twofold. First, I got quite a sense of déjà-vu since it hearkened back to my time as an undergraduate and memories of many heated discussions about whether code was self-documenting.

by Terry Coatta | July 14, 2008

CACM This article appears in print in Communications of the ACM, Volume 5 Issue 6


Solomon’s Sword Beats Occam’s Razor:
Choosing your best hypothesis

I’ve told you a googol times or more: Don’t exaggerate! And, less often, I’ve ever-so-gently urged you not to understate. Why is my advice ignored? Why can’t you get IT... just right, balanced beyond dispute? Lez Joosts Mildews, as my mam was fond of sayin, boxing both my ears with equal devotion. Follow the Middle Way as Tao did in his Middle Kingdom. Or "straight down the middle," as golfer Bing Crosby used to croon. His other golf song was "The Wearing of the Green," but such digressions run counter to my straight, plow-on-ahead advice.

by Stan Kelly-Bootle | April 28, 2008


All Things Being Equal?:
New year, another perspective

By the time these belles-lettres reach you, a brand new year will be upon us. Another Year! Another Mighty Blow! as Tennyson thundered. Or as Humphrey Lyttelton (q.g.) might say, "The odious odometer of Time has clicked up another ratchette of entropic torture." Less fancifully, as well as trying hard not to write 2007 on our checks, many of us will take the opportunity to reflect on all the daft things we did last year and resolve not to do them no more. Not to mention all the nice things we failed to do. I have in mind the times when I missed an essential semicolon, balanced by the occasions when inserting a spurious one was equally calamitous.

by Stan Kelly-Bootle | March 4, 2008


Poisonous Programmers:
A koder with attitude, KV answers your questions. Miss Manners he ain’t.

Dear KV, I hope you don’t mind if I ask you about a non-work-related problem, though I guess if you do mind you just won’t answer. I work on an open source project when I have the time, and we have some annoying nontechnical problems. The problems are really people, and I think you know the ones I mean: people who constantly fight with other members of the project over what seem to be the most trivial points, or who contribute very little to the project but seem to require a huge amount of help for their particular needs. I find myself thinking it would be nice if such people just went away, but I don’t think starting a flame war on our mailing lists over these things would really help.

by George Neville-Neil | March 4, 2008


Use It or Lose It:
Aphorisms in the abstract

My aphorisme du jour allows me to roam widely in many directions, some of which, I hope, will be timely and instructive for Queue readers. My choice of the French aphorisme is a justifiably elitist affectation, paying homage to Montaigne, Voltaire, Bertrand Meyer, and that cohue d’elegance. The Gallic gargled r (as in Brassens) and the sublime long final syllable, if you get them right, simply drip with class compared with the slovenly sequence of English diphthongs: a-for-iz-um. We tend to treat the terms aphorism and epigram as posh synonyms for maxim, motto, or even saying.

by Stan Kelly-Bootle | January 17, 2008


The Code Delusion:
The real, the abstract, and the perceived

No, I’m not cashing in on that titular domino effect that exploits best sellers. The temptations are great, given the rich rewards from a gullible readership, but offset, in the minds of decent writers, by the shame of literary hitchhiking. Thus, guides to the Louvre become The Da Vinci Code Walkthrough for Dummies, milching, as it were, several hot cows on one cover. Similarly, conventional books of recipes are boosted with titles such as The Da Vinci Cookbook—Opus Dei Eating for the Faithful. Dan Brown’s pseudofiction sales stats continue to amaze, cleverly stimulated by accusations of plagiarism and subsequent litigation.

by Stan Kelly-Bootle | November 15, 2007


The Next Big Thing:
The future of functional programming and KV’s top five protocol-design tips

Dear KV, I know you did a previous article where you listed some books to read. I would also consider adding How to Design Programs, available free on the Web. This book is great for explaining the process of writing a program. It uses the Scheme language and introduces FP. I think FP could be the future of programming. John Backus of the IBM Research Laboratory suggested this in 1977. Even Microsoft has yielded to FP by introducing FP concepts in C# with LINQ.

by George Neville-Neil | November 15, 2007


Ground Control to Architect Tom...:
Can you hear me?

Project managers love him, recent software engineering graduates bow to him, and he inspires code warriors deep in the development trenches to wonder if a technology time warp may have passed them by. How can it be that no one else has ever proposed software development with the simplicity, innovation, and automation being trumpeted by Architect Tom? His ideas sound so space-age, so futuristic, but why should that be so surprising? After all, Tom is an architecture astronaut!

by Alex Bell | November 15, 2007

CACM This article appears in print in Communications of the ACM, Volume 5 Issue 6


Some Swans are Black:
…and other catastrophes

You may well expect from my title that I’m about to plumb the depths of Nassim Nicholas Taleb’s theories on catastrophe and quasi-empirical randomness. I, in turn, expect that you’ve already read Taleb’s best-selling The Black Swan—The Impact of the Highly Improbable dealing with life’s innate uncertainties and how to expect or even cope with the unexpected.

by Stan Kelly-Bootle | August 16, 2007


Ode or Code? Programmers be Mused!:
Is your code literate or literary?

My sermon-text this grumpy month is Matt Barton’s article “The Fine Art of Computer Programming”, in which he extols the virtues of what is widely called literate programming. As with the related terms literary and literature, we have ample room for wranglings of a theological intensity, further amplified by disputes inherent in the questions: “Is computer science or art?” and “What do programmers need to know?” Just as we must prefer agile to clumsy programming, it’s hard to knock anything literate.

by Stan Kelly-Bootle | May 4, 2007


Advice to a Newbie:
A koder with attitude, KV answers your questions. Miss Manners he ain’t.

Dear KV, I am new to programming and just started reading some books about programming, particularly C++ and Visual Basic. I truly enjoy programming a lot, to the extent that for the past couple of months I have never missed a day without writing some code. My main concern now is what the world holds for programmers. If someone is called a programmer (i.e., professionally), what will he or she really be programming? As in, will you always be inventing new software or what, really? This is mainly in the case of someone who will not be working for someone else.

by George Neville-Neil | May 4, 2007


Will the Real Bots Stand Up?:
From EDSAC to iPod—predictions elude us

When asked which advances in computing technology have most dazzled me since I first coaxed the Cambridge EDSAC into fitful leaps of calculation in the 1950s, I must admit that Apple’s iPod sums up the many unforeseen miracles in one amazing, iconic gadget. Unlike those electrical nose-hair clippers and salt ’n’ pepper mills that gather dust after a few shakes, my iPod lives literally near my heart, on and off the road, in and out of bed like a versatile lover—except when it’s recharging and downloading in the piracy of my own home.

by Stan Kelly-Bootle | December 28, 2006


Saddle Up, Aspiring Code Jockeys:
A koder with attitude, KV answers your questions. Miss Manners he ain’t.

Dear KV, I am an IT consultant/contractor. I work mainly on networks and Microsoft operating systems. I have been doing this work for more than eight years. Unfortunately, it is starting to bore me. My question is: How would I go about getting back into programming? I say getting back into because I have some experience. In high school I took two classes of programming in Applesoft BASIC. I loved it, aced everything, and was the best programming student the teacher ever saw. This boosted my interest in computer science, which I pursued in college. In college, I took classes in C++, Java, and Web development.

by George Neville-Neil | October 10, 2006


Facing the Strain:
A koder with attitude, KV answers your questions. Miss Manners he ain’t.

Dear KV, I’ve been working on a software team that produces an end-user application on several different operating system platforms. I started out as the build engineer, setting up the build system, then the nightly test scripts, and now I work on several of the components themselves, as well as maintaining the build system. The biggest problem Ive seen in building software is the lack of API stability. It’s OK when new APIs are added--you can ignore those if you like--and when APIs are removed I know, because the build breaks. The biggest problem is when someone changes an API, as this isn’t discovered until some test script--or worse, a user--executes the code and it blows up.

by George Neville-Neil | September 15, 2006


Software Development Amidst the Whiz of Silver Bullets...:
A call to Transylvania may be needed.

Veterans of the software industry will attest to having seen a number of silver bullets come and go in their time. The argentum projectiles of yesteryear, such as OO, high-level software languages, and IDEs, are now obvious to have been only low-grade alloys compared with the fine silver being discharged today. For example, today’s silver bullets have demonstrated an unparalleled ability to provide implicit value to both text and diagrams, the power to shift the economics of software development, and a capacity to change the focus of long-established engineering disciplines.

by Alex E. Bell | June 30, 2006


The Calculus Formally Known as Pi:
The hype over the pi-calculus

Dominic Behan once asked me in a rare sober moment: “What’s the point of knowing something if others don’t know that you know it?” To which I replied with the familiar, “It’s not what you don’t know that matters, it’s what you know that ain’t so.” I was reminded of these dubious epistemological observations while reading Stephen Sparkes’ interview with Steve Ross-Talbot in the March 2006 issue of ACM Queue.

by Stan Kelly-Bootle | June 30, 2006


But, Having Said That, ...:
80 percent of the useful work is performed by 20 percent of the code.

A persistent rule of thumb in the programming trade is the 80/20 rule: "80 percent of the useful work is performed by 20 percent of the code." As with gas mileage, your performance statistics may vary, and given the mensurational vagaries of body parts such as thumbs, you may prefer a 90/10 partition of labor. With some of the bloated code-generating meta-frameworks floating around, cynics have suggested a 99/1 rule - if you can locate that frantic 1 percent. Whatever the ratio, the concept has proved useful in performance tuning.

by Stan Kelly-Bootle | March 29, 2006


Anything Su Doku, I Can Do Better:
The new puzzle craze from japan is sweeping the world, and testing our Boolean logic.

I dedicate this essay in memoriam to Jef Raskin. Many more authoritative tributes than I can muster continue to pour in, and no doubt a glorious Festschrift will be forthcoming from those who admired this remarkable polymath. "Le don de vivre a passé dans les fleurs."

by Stan Kelly-Bootle | January 31, 2006


Coding for the Code:
Can models provide the DNA for software development?

Despite the considerable effort invested by industry and academia in modeling standards such as UML (Unified Modeling Language), software modeling has long played a subordinate role in commercial software development. Although modeling is generally perceived as state of the art and thus as something that ought to be done, its appreciation seems to pale along with the progression from the early, more conceptual phases of a software project to those where the actual handcrafting is done.

by Friedrich Steimann, Thomas Kühne | January 31, 2006


Syntactic Heroin:
A dangerous coding addiction that leads to a readability disaster.

User-defined overloading is a drug. At first, it gives you a quick, feel-good fix. No sense in cluttering up code with verbose and ugly function names such as IntAbs, FloatAbs, DoubleAbs, or ComplexAbs; just name them all Abs. Even better, use algebraic notation such as A+B, instead of ComplexSum(A,B). It certainly makes coding more compact. But a dangerous addiction soon sets in. Languages and programs that were already complex enough to stretch everyone’s ability suddenly get much more complicated.

by Rodney Bates | July 6, 2005


File under "Unknowable!":
It’s been ahard day’s night—proving nonexistence!

The Yellow Pages used to advertise along the following lines: “If you can’t find it here, it does not exist.” Shannan Hobbes, my favorite epistemologist, and I would ponder this claim well into the wee hours, testing its validity by searching for vendors of “Square Circles,” “Pet Unicorns,” “Cold Fusion,” “The Largest Prime Number,” “Reigning Bald Kings of France,” and similar quiddities oft debated in the PhilTrans (Philosophical Transactions). Our mounting failures—or, to quickly remove the scandalous ambiguity—our growing number of “not founds” amounted to some sort of inductive verification (of which, more anon). The Yellow Pages, considered as a merely finite hierarchy of marketable strings, has nothing much to tell us of contingent, objective existence.

by Stan Kelly-Bootle | April 21, 2005


Comments are More Important than Code:
The thorough use of internal documentation is one of the most-overlooked ways of improving software quality and speeding implementation.

In this essay I take what might seem a paradoxical position. I endorse the techniques that some programmers claim make code self-documenting and encourage the development of programs that do “automatic documentation.” Yet I also contend that these methods cannot provide the documentation necessary for reliable and maintainable code. They are only a rough aid, and even then help with only one or two aspects of documentation—not including the most important ones.

by Jef Raskin | March 18, 2005


Without a NULL That String Would Never End:
N-streak, 1-streak, worra streak

It’s an undiluted pleasure to be invited to contribute a third column for ’ACM Queue’ under the surly rubric “Curmudgeon.” Curmudgeons are not usually associated with pleasures, diluted or full strength, but at my age the cheap thrill of thrusting a poisoned pen is especially welcome since the targets for satire bob daily as upstart sitting ducks for the roasting: mere “Juvenal delinquents,” as master curmudgeon George Crabbe [sic] called them.

by Stan Kelly-Bootle | August 31, 2004


Damnéd Digits:
Floating in the real world of real numbers

I remind you, first, that "damnéd" has two syllables, calling for a Shakespearean sneer as sneered by Olivier strutting his King Richard III stuff.

by Stan Kelly-Bootle | April 16, 2004


Reading, Writing, and Code:
The key to writing readable code is developing good coding style.

Forty years ago, when computer programming was an individual experience, the need for easily readable code wasn’t on any priority list. Today, however, programming usually is a team-based activity, and writing code that others can easily decipher has become a necessity. Creating and developing readable code is not as easy as it sounds.

by Diomidis Spinellis | December 5, 2003


No Source Code? No Problem!:
What if you have to port a program, but all you have is a binary?

Typical software development involves one of two processes: the creation of new software to fit particular requirements or the modification (maintenance) of old software to fix problems or fit new requirements. These transformations happen at the source-code level. But what if the problem is not the maintenance of old software but the need to create a functional duplicate of the original? And what if the source code is no longer available?

by Peter Phillips, George Phillips | October 2, 2003