Introduction
A lot of the topics this week seem to be justifications for taking an engineering approach. That's OK, we absolutely should question our assumptions and ensure that what we're doing is for the right reason! In my own writing, I talk about when to deal with “engineering requirements” and technical debt, and then why my recommendation is as opinion-led as anyone else's. Out on the web, we find out how trivial some people think software engineering is, and why Ron Jeffries disagrees with you that some paradigm/method has “failed”.
Writing
When to “address” “technical debt”?
Plenty of teams try to get their engineering tasks prioritised in different ways, and of all of these I've only seen one that works.
Why are we like this?
Following on from my post on addressing technical debt, I explore why these decisions are so often opinion-led not evidence-led.
What went wrong? Reverse-engineering disaster
This is an old (2017) piece I wrote for the Wealth Wizards Engineering blog, and I believe the only thing I ever wrote on Medium. I still believe strongly in blameless post-mortems and recently led one on a troublesome rollout at Global.health.
Unit test: you keep using this word.
In which I correct some Humpty-Dumptyism by looking at what everybody else means by a phrase. I appreciate this may feel like snipey pedantry, I would like to argue that using terms of art correctly is important. It's important for accurately communicating to people how we do our work, so that the best practices can be passed on, adopted, and evolved.
Audio
Episode 52: Software Freedom is a Civil Liberties Issue
It’s time to remember that free software isn’t about enabling SaaS startups, though of course they are free to use the software too.
Since I recorded this, I read Brad Kuhn’s article which makes another, related point. If we all chose our pet social justice issues to attach to our variation of free software, we would balkanise the free software movement (even further than is currently the case). Political action like free software campaigning relies on people coming together on the things they can agree on, even when they then disagree on other things.
And software lawyer Kyle E. Mitchell has a different perspective on the Neo4J case: it had nothing to do with open source as a term of art, and everything to do with the specific advocacy of the two sides in this case. As he’s a software law expert I’m going to accept his interpretation: consider this a correction to that segment of the podcast episode.
Around the web
The Hardest thing about Engineering is Requirements
As I’ll say to anyone who listens, and many who won’t, an engineering team thrives or fails based on whether it’s building the right thing. Building the thing right is a clear second place concern. Jay analyses problems with “requirements gathering” and comes to the “user case”, which I call “the back of the index card”. As far as I’m concerned, a user story is a placeholder to remember what you (collectively) want the software to do. It goes on the front of the card. The back of the card is now empty: use it to record interesting detail and buildable information.
Don't build (or build) that feature
I keep saying that buy vs build is one of the most important engineering decisions ever made. This fun little calculator shows how to think about that decision.
No other profession trivialises their profession to the degree of software
Another salvo in the “should software engineers be licensed” battle. Fair warning: I’m doing a doctorate on this very topic, so can expound at length 😴. Here, the argument is that software engineering mentoring is the quite inexperienced leading the very inexperienced, due to the growth in the field. The actually experienced can be found: Kent Beck, Ron Jeffries, Grady Booch, Linda Rising, Barbara Liskov are all sharing what they know; I’ve met and continue to meet each on my journey.