Software design

This category contains 38 posts

Requirements are entangled with design

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 design; this is how we should implement it.” He had a different point of view, and was saying “These are requirements; we are free to … Continue reading

If you need an FAQ you’ve done it wrong

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 ago from GDS, and also a tweet from James Hupp, who said, “FAQs are a way to show you’ve thought about what your users should … Continue reading

The word puzzle analogy for technical changes

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, and we need to discuss how to approach it. In years gone by, before continuous deployment was the norm and microservices were popular, it usually … Continue reading

Plan for legacy systems

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 in particular caught my eye: To truly add a level of responsive interactivity to our application, we need to understand Signals, Mailboxes, and Addresses. These … Continue reading

Deploy first, build after

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 were building a system which, er, did something. I can’t remember exactly what it was, but I think it probably involved an FTP server, which … Continue reading

Anti-needs

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 roughly the same: an expression of what (we believe) people need. We even have people for whom this is a significant part of their job. … Continue reading

The benefits of timeboxing a solution

A colleague pointed me to a nice article by Sue Davis about writing for the public, and among the suggestions was the idea of timeboxing feedback: “If you don’t, the polishing process can be never-ending and you risk delaying getting the content to your users.” Timeboxing is really valuable not just for getting feedback, but … Continue reading

Discovering the Elm language

Are you looking for a better front-end coding experience? I’ve just spent several weeks completing my first project with the Elm language. This is my experience. (Spoiler alert: It’s pretty positive.) Background I’m a hobbyist coder. I work with software developers as my day job and envy their skill and dedication; I can sit down … Continue reading

Technical bankruptcy

Lukas Oberhuber, CTO of Simply Business, has surfaced a term I think a lot of people will find hugely useful, and which really should be used more widely: technical bankruptcy. He introduces it in a presentation seen on Skills Matter, but also elsewhere. And it’s used to solve a very important problem: How to explain … Continue reading

Keeping up to date aggressively

A software developer friend of mine has good advice, which he repeats solemnly: “You have to keep up to date aggressively .” I agree. He is specifically talking about software libraries and platforms. If you don’t keep up to date with minor releases that come out then the changes you need to make for the … Continue reading