[Oldletter #27] The Business of SaaS, broken software hiring and defending Not-Invented-Here syndrome

📢 Quick announcement: if your team is struggling with production bugs and poor testing in your serverless application, I’ve just launched a new Serverless Testing Audit service that you may be interested in.

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

• The Business of SaaS by Patrick McKenzie, whose online writings first got me interested in SaaS. A detailed overview of the business model of SaaS. Particularly interesting to note the differences between low-touch and high-touch companies and the several benchmarks he quotes.

  The SaaS model fundamentally works by financializing software: Instead of selling software as a product with a sticker price, it sells the software as if it were a financial instrument, with a probabilistically forecastable cash flow.

• The Hiring Post (2015) by Thomas Ptacek. A seven-year old piece on how broken the software engineering hiring process is and some suggestions on how to fix it. Going by my LinkedIn timeline, it still seems broken in many companies today. I particularly enjoyed this quote:

  There may be no cohort of professionals less qualified to assess barely-tangible socio-psychological attributes like “passion” and “confidence” than the modern software nerd. Random employees conducting random interviews based in part on subjective psychological assessments, each producing not data but a “hire/no-hire” recommendation, reassembled by a hiring manager into a decision that would be made only marginally less rigorous if it also involved a goat sacrifice.

• In Defense of Not-Invented-Here Syndrome (2001) by Joel Spolsky. NIH syndrome, where teams insist on building everything in-house, is generally accepted as a bad way to run a software organisation. But this piece argues for cases where a little bit of it does make sense.

  If it’s a core business function — do it yourself, no matter what. Pick your core business competencies and goals, and do those in house. If you’re a pharmaceutical company, write software for drug research, but don’t write your own accounting package. If you have customers, never outsource customer service.

---

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!

— Paul