[Oldletter #22] Testing in production, Jobs To Be Done and The Duct Tape Programmer
📢 Quick announcement: if your team needs any help with building a serverless app on AWS, I may have some availability over the next 2 months to work with you. Just reply to this email and we can set up a call.
Every Friday, I’m sharing a short list of evergreen articles/resources broadly related to software engineering that wouldn’t typically get shared in most tech newsletters or social media feeds.
This week’s links
Testing in production, yes you can (2017) by Charity Majors. A strong case for why (and a little how) to test your software in production.
It seems testing in production has gotten a bad rap—despite the fact that we all do it, all the time. Maybe we associate it with cowboy engineering. We hear “testing in production” and assume this means no unit tests, functional tests, or continuous integration.It’s good to try and catch things before production—we should do that too! But these things aren’t mutually exclusive.
What is “Jobs to be done”? (2017) by Tony Ulwick. A theory for approaching the design of products and services. This article lists out 9 core tenets of the theory.
The JTBD theory is based on the notion that people buy products and services to get a “job” done. Jobs Theory goes on to say that by understanding in detail what that “job” entails, companies are far more likely to create and market solutions that will win in the marketplace.
The Duct Tape Programmer (2009) by Joel Spolsky. In favour of pragmatic programmers who focus on shipping and minimising complexity.
Everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness has come down from the architecture astronauts who speak at conferences and write books and articles and are so much smarter than us that they don’t realize that the stuff that they’re promoting is too hard for us.
The duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”
Submitting your recommendations
If you’d like to share an evergreen article/book which has significantly influenced your thinking or practice around software delivery, please email it through to me and I’ll add it to my backlog for sharing in future editions.
Have a great weekend!
Indie Cloud Consultant helping small teams learn and build with serverless.
Learn more how I can help you here.
Join daily email list
I publish short emails like this on building software with serverless on a daily-ish basis. They’re casual, easy to digest, and sometimes thought-provoking. If daily is too much, you can also join my less frequent newsletter to get updates on new longer-form articles.