In the last week, I've had some kind comments telling me how useful some of my articles have been to their thinking and their work.

In case they are also useful to you, here they are... Changing Your Priorities

"In recognizing that priority is not a singular concept, we should not be looking to make it one just for the sake of linear ordering. Priorities form a landscape, not a line."

kevlinhenney.medium.com/changing-your-…

There is a peculiar irony to how the pendulum has swung on exactness of searches in software systems.

E.g., searching of text, a dataset, emails, products, accounts, etc., for a word, phrase, etc. The easiest thing to do in code is to match exactly. And this used to be a limitation. You often also want something approximate, to widen your search. You might not remember a name or title exactly.

These days, however, it seems almost impossible to get exact matches.

If placing each argument on its own line in a call is normal in your codebase, it's worth taking a step back and figuring out what cause(s) have led to this effect. Are long argument lists common? People often like to put an upper limit to this, but that's not always either necessary or helpful — people often work to measured limits.

It's normally obvious when this is an issue, so look for the effects, e.g., one argument per line.

I've had the opportunity to run the Gilded Rose refactoring kata with different groups a few times in the last year.

There are a number of interesting things I've observed, and not simply in the kinds of solution styles that people pursue. If you've not tried it, it's worth a look: github.com/emilybache/Gil…

Unfortunately, most blogs I've seen on it either give unnecessarily complex solutions or they provide a good starting point for further refactoring, i.e., they're en route to a solution, but not quite there yet.

It feels like we are living in a post-GUI era.

The interaction of most user interfaces is structured around lists and text plus buttons. Visualisation is based on these, plus images (embedded/featured, moving/static, etc.).

It's a disappointingly primitive set of primitives. It's not that lists and text aren't useful but, as almost every social media site and app shows, they're very poor at representing and manipulating many subjects of interest.

Modern UI design shows a widespread lack of imagination that is disappointing given the possibilities.

I find there's an important mindset difference between talking about 'eliminating' something — such as bugs, risk or technical debt — and 'reducing' something.

The difference has important implications for ways of work, methodologies, etc. and what we measure or focus on. The word 'eliminate' is somewhat absolute, and inevitably sets you up to fail. It's framed as a finite game rather than an infinite game, i.e., it focuses on a completion state of something rather than something that is ongoing.

We often talk about design trade-offs, but fail to notice the implication of the term 'trade-off': it's a trade.

A trade denotes exchanging one quality/quantity for another. A good trade is, therefore, one in which what we receive is of greater value to us than what we give up. For example, we might trade some code simplicity for an improvement in some aspect performance. If that extra performance is something that we needed, the increased complexity of the code is worth it. If it isn't, then it isn't.

Nothing dates a software development book faster than using screenshots.

This is, of course, entirely appropriate if the book teaches you how to use version X.Y of product Z — screenshots of Z make it real and relevant — otherwise, screenshots become quaint surprisingly quickly. If you want to show code or command lines, use text not screenshots. This also has the benefit of being more readable (images are great for actual pictures, not so good for text), under your control and does not age so poorly.

One of the issues I see with how people report test coverage is that they normally use a shorthand, and often without knowing it: you often hear something like "We have 80% coverage" when what the speaker intended to say was "We have 80% statement coverage". Why does this matter? Partly because proximity to 100% suggests, in many people's minds, completeness, that the test suite is 'full' or that there's no more that could or should be done.

This is illusory.

A couple of days back, I asked a style question about use of field initialisers vs initialisation in constructors.

There were some interesting replies, some more considered than others, and where some insight into the style preference was given.

https://twitter.com/KevlinHenney/status/1293808375210422272

That said, the issue also revealed some interesting contradictions, which I don't think were resolved, and which were what triggered my question in the first place.

Logic is something humans struggle with, even (especially...?) if they're software developers.

It comes out in conditions in production code, but also in testing, so that conditions are tested for that are not necessarily the case, leading to brittle, overfitting tests. For example, one I see in production tests, courses and blogs is the following:

# (1) Given a == b then
assert hash(a) == hash(b)

# (2) Given a != b then
assert hash(a) != hash(b)

(1) is a requirement of any equality contract. (2) is only true for perfect hashing.

When talking about reducing mutability of state in imperative code, most of the focus tends to be on objects and the explicitly represented data and variables themselves, i.e., reduce incidence and possibility of assignment, eliminate methods with side-effects, etc. What's often overlooked is control state and the implicit and explicit tracking of state in imperative control flow.

The more you need to run a program counter in your head and track changes and roles across variables, the greater the complexity, the more likely errors become.

My impression is that most tutorials on mocking and mocking frameworks lead with how to stub code for tests than how to actually use mocks for testing.

Such priming might explain many common misunderstandings around mocking, as well as the parlous state of many mock-based tests. The gratuitous complexity of many mockish tests is testament to the human condition and blind spots in thinking.

Developers invest more time figuring out how to stub problem code, creating tests more complex than the code being tested, than in simplifying the code being tested.

Last week I ran a remote training course for a client. It went surprisingly well. Some things went well because of planning; some things went well because of luck. Some things went poorly in spite planning; some things went poorly because of luck. The course was supposed to be a 4-day onsite course. It was converted into a 4-day online course as that is the duration that was promised.

I would not recommend this duration. A 2-day course run over 2 days or 4 half days is kind of the limit.

Doing agile development at scale is not necessarily the same as scaling agile development.

The latter suggests taking an existing agile development and changing the scale, whereas the former may involve imposition of an agile approach at an existing scale. In many cases, when people are discussing scale and agility, there is an assumption that the scale is necessarily large or larger than some current size.

Scale and scaling work both ways. Question the assumption: sometimes what development needs is scaling down not up.