Previously I’ve written about Niels Malotaux’s drive for zero defects. One of his principles (and the IBM Clean Room approach) is that any failure, such the as the discovery of … Continue reading Literate programming part 1: What is it?
The other day I was having a conversation with someone about requirements and software design. We had a description for a small system, and I was saying “this is the … Continue reading Requirements are entangled with design
One thing I often say to people I work with is, “If you need an FAQ you’ve done it wrong.” This idea stems from a blog post I read ages … Continue reading If you need an FAQ you’ve done it wrong
I’ve often come across a situation where a team needs to undertake a major refactoring or some other technical change, which may take in the order of days or weeks, … Continue reading The word puzzle analogy for technical changes
The other day I was looking at some old Elm code, refamiliarising myself with one of the key language concepts (Signals) and found an article to help me. One part … Continue reading Plan for legacy systems
There’s a lesson I learned a long time ago, and which I still find useful: deploy first, build after. Many years ago, when I was working with Mat Wall, we … Continue reading Deploy first, build after
In the tech industry we’re reasonably good at capturing needs. Sometimes we skip the needs (or assume them) and go straight to requirements. That’s not great, but the intention is … Continue reading Anti-needs