@sleepyfox sleepyfox

author: @sleepyfox
title: Alexandrian Architecture
date: 09-Jan-2023

Alexandrian Architecture

My New Year's resolution: I am not going to talk about Micro-services.

author: @sleepyfox
title: The problem with AI coders
date: 22-Jun-2022

The problem with AI coders

The problem with 'solutions' like GitHub's Copilot, and similar tech, is that it frames the problem as a problem of search. The programmer is searching for some code that does a thing (produce a HTML table with alternating coloured background rows of green and red), and that they just need to find that thing. Machine Learning has had success in this area, just look at Google's page-rank 'algorithm'.

author: @sleepyfox
title: Aikido and the philosophy of software development
date: 11-Oct-2013

Aikido and the Philosophy of Software Development

I ran an impromptu session at the Software Craftsmanship and Testing conference in the UK a couple of weeks ago, that turned out to be rather well received - though I suspect that this was more due to the novelty of the session rather than anything else. The spark that led to this session was a tweet by James Coplien that both he and Jeff Sutherland practice Aikido, re-tweeted by Bob Marshall.

It led me to think that if one of the two founders of Scrum were positively influenced by Aikido, perhaps Aikido has had other influences within the IT world that we are perhaps unaware of, and perhaps it would be worth talking with people about.

author: @sleepyfox
title: Demon ex machina
date: 03-Jul-2008

Demon ex Machina

Why are speed cameras like software metrics? Speed cameras are (or so we are told in the UK) a 'Road Safety initiative' that is designed to reduce the number of fatalities and serious injuries in road traffic accidents. A software metric is measurement of a software system's properties that is used (or so we are told) to increase quality and decrease cost and risk from software development projects.

author: @sleepyfox
title: The invisible deficit
date: 10-Mar-2012

The invisible Deficit

I read with interest a tweet from Kent Beck the other day as it seemed to ring a bell: "The complexity created by a programmer is in inverse proportion to their ability to handle complexity". He followed up the tweet with a note on his Facebook page explaining that he'd been doing a code review of a developer's code and noticed that the guy didn't recognise that the solution he'd adopted was needlessly complex compared to the problem, but the developer simply couldn't see it. Kent finished with "The programmer least likely to be able to handle the extra complexity is exactly the one most likely to create it. Seems a little unfair. I'm interested in how to break this cycle, and whether it is even possible to break this cycle." (emphasis mine).

A link in the comments led me to the Dunning-Kruger effect, and a light bulb came on as I recognised a friend's comment from last week that none of the rest of the d

author: @sleepyfox
title: Time to decelerate
date: 30 October 2020 
preamble: Sometimes going ever faster is not the answer

Time to decelerate

Imagine you're an alien from another world, a crustacean-like species from an ocean world orbiting Epsilon Eridani, and you're researching Earth civilisation and culture. You're interested in the whole earthling obsession with quality and food, Michelin stars and celebrity chefs. On your world food is fuel, you eat rocks. Rocks provided by your world government as a service to citizens. There are no restaurants.

author: @sleepyfox
title: Preview-Driven Development
date: 18 October 2020
preamble: Doing the PR review before the code is written is more helpful, just like TDD

Preview-Driven Development[^0]

Reader's note: these notes were originally written to support a SimplyBusiness tech talk, so is written with some embedded context which I hope to explain or remove in a future edit - my apologies for any confusion that this may cause the reader.

Software Engineering, 1968/69 NATO Conference Garmisch/Rome

Many people are aware that in 1968 an inaugural conference in Software Engineering was held in Garmisch, Germany under the auspices of NATO, and that a follow-up conference was organised the next year, 1969 in Rome, Italy.

Although the reports from those two conferences are reasonably well distributed, if not perhaps as well read, there exists an appendix that the report editor, Brian Randell, notes:

Unlike the first conference, at which it was fully accepted that the term software engineering 
expressed a need rather than a reality, in Rome there was already a slight tendency to talk as 
if the subject already existed. And it became clear during the conference that the organizers

author: @sleepyfox
title: Fox's laws of software development
date: 27 October 2021
preamble: A not entirely serious treatise on the immutable fundamental laws of software development activities

Fox's laws of software development

A not entirely serious treatise

	// Prototypal inheritance example
	// Checked on Node v16.14.2
	assert = require('assert')

	// A cat goes 'meow'
	class Cat {
	goes() {
	return 'meow'
	}
	}