A calendrical journey into low-level programming

(TL;DR: for the impatient, see here and here. For everyone else, read on…)

A calendar system is an attempt to make sense of the passing of time with respect to astronomical phenomena — the positioning of the Sun, the Moon and the stars with respect to our unfixed and moveable Earth. It is perhaps ironic, then, that the widely used Gregorian calendar system is a cobbled-together mishmash that better reflects the arbitrariness of history than it does either celestial order or logical consistency.

The division of the year into months based in some way on the cycle of the Moon…

The what, how, and why of prioritizing development work

This article first appeared in agile-thoughts

What should we do next? What’s the most important thing? What’s the most urgent thing? What’s the riskiest thing? What’s the surest thing? What’s the quickest thing? What’s the thing that is likely to have the greatest long-term financial return on investment? What’s the thing that creates the most opportunities? What’s the thing that most likely generates the greatest revenue in the short term? What’s the thing that will most benefit the development team? What’s the thing that is currently of most interest to our customer? What’s the thing that we should already have done but haven’t? What’s the thing…

An unexpected paradigm journey into sleep sort

A decade ago I first presented a lightning talk entitled Cool Code. This short talk evolved into a full talk whose iterations I presented over the next half decade. The focus? Code that, for some reason or other, can be considered cool. For example, code that has played a significant role in historical events, such as the source for the Apollo Guidance Computer. Or code that is audacious — if not seemingly impossible — given its constraints, such as David Horne’s 1K chess. There is code that is both simple and profound, such as Peter Norvig’s fits-on-a-slide spelling corrector. …

When code throws or catches an exception, name to communicate rather than regurgitate

A previous version of this article appeared in NDC Developer Magazine

One of the hardest things in software development is naming. Naming of products, of paradigms and of parts of your code. The reason naming is both hard and important is because it is an act of communication; without good names your code might as well be written in, well, code. A name is not simply a label: it informs and guides the reader’s mental model. Names can change the way the reader thinks. A good name is a sharing of minds; a poor name is a missed opportunity to learn and say what we mean.

We often adopt conventions to…

An essay on paradigms, refactoring, control flow, data, code, dualism and what Roman numerals ever did for us

Looking at something from a different point of view can reveal a hidden side. With physical objects this hidden side can be literal, hence why technical drawings of three-dimensional objects are often made using a multi-view projection, such as a plan view and elevation views. With abstract concepts the hidden side is more figurative. In software architecture, for example, view models, such as 4+1 or ODP viewpoints, can be used to bring different concerns of a system into focus, such as user interaction, governance, behaviour, code structure, information model, physical distribution, infrastructure, etc.

Numeral systems also have this quality. Changing…

Assertions should be necessary, sufficient, and comprehensible

A previous version of this article appeared in 97 Things Every Programmer Should Know

It is important to test for the desired, essential behaviour of a unit of code, rather than for the incidental behaviour of its particular implementation. But this should not be taken or mistaken as an excuse for vague tests. Tests need to be both accurate and precise.

Something of a tried, tested, and testing classic, sorting routines offer an illustrative example — they are to computer science as fruit flies are to genetics. Implementing sorting algorithms is far from an everyday task for a programmer, commodified as they are in most language libraries, but sorting is such a familiar idea…

The challenge is not to write comments for what code does not say, but to write comments for what code cannot say

A previous version of this article appeared in 97 Things Every Programmer Should Know

As with any other form of writing, there is a skill to writing good comments in code. And, as with any other form of writing, much of the skill is in knowing what not to write.

It has been said that the difference between theory and practice is greater in practice than it is in theory. This observation certainly applies to comments. In theory, the general idea of commenting code sounds like a worthwhile one: offer the reader detail, an explanation of what’s going on. What could be more helpful than being helpful? …

The number of days in a year is 365 or 366… or more or less

In jumping from calendars that are a distance apart and moving at different speeds, you need to change gears to get the two in sync. This can upset the regularity of our expectations:

I said that calendar years have one of two day counts: 365 and 366 days. In the Gregorian and Julian calendars this is true… but when jumping from one system to another, truth is more fluid.

In the default case you take the baseline of 365 days and add an optional leap year. In exceptional cases, such as changing from the Gregorian to the Julian calendar, you…

When is the same date not the same day?

It’s 23rd April, World Book Day, as I write this.

Miguel de Cervantes and William Shakespeare both died on 23rd April 1616. They did not, however, did not die on the same day. There is no paradox, but there is an assumption: these dates of death do not come from the same calendar.

In 1616 Spain was following the Gregorian calendar, introduced by and named for Pope Gregory XIII in October 1582, and England was still following the Julian calendar, based on Julius Caesar’s calendar reforms in 46 BCE. …

The one where my software and creative writing worlds collide

Behind every story lies a story. This one begins one Saturday morning in Malmö. To be precise, Saturday 7th March at the single-day, single-track Beauty in Code conference. I’m speaking in the afternoon. Just before nine o’clock, however, I’m still upstairs in my hotel room, taking it easy.

Just then I receive a WhatsApp message: “Are you coming down?” It’s from Alistair Cockburn, who’s giving both the opening talk of the day, Getting back to the Heart of Agile, and the closing one.

“Yes, but not for a few minutes. Got caught in an email.”

“I’m going to ask you…

Kevlin Henney

consultant · father · husband · itinerant · programmer · speaker · trainer · writer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store