Software Economics, by Luis Artola, is a book for Engineering to be aligned with Business, through cost-effective techniques. It’s a self-awareness and introspection challenge that addresses questions like “why are we doing this?” whenever you’ve lost your focus among technological mazes or silver-bullet promises. I’d say that it’s also relevant to Business, and to any manager that comes up with short-sighted arguments about profitability. If the person you report to is the kind of boss that complains about team doing “too many tests”, you can probably have a constructive discussion once you both read this book, becase instead of talking in your own domain of expertise and concern you’ll meet talking about midterm return of investment or risk reduction.
The key of the book is the usage of economic language as a tool both for communication and reasoning, from investment to debt or mortgages. Sometimes it can be seen as a metaphor, because it’s more abstract than what you might be used to, but once you get used to it, you realize that it’s way more specific than what it looks like. For example, in the 1.1 section, about protecting an investment, the key sentence is that “an investment has three elemental variables: profitability, risk and liquidity”. You’d better get used to that kind of language soon, there’s a glossary I encourage reading early. Anyway, that kind of sentences are exactly what I expect from this book: setting a shared language and a framework that we agree upon, enabling valuable conversations, arguments, and learnings.
It’s divided in three parts. The first one, “Protecting an investment”, is, as you would expect, the most generic one, with many terms that are required afterward. It should align your vision about software development with the one from the author. The second one, “Cost reduction”, is mostly about code design and refactoring. It’s a compendium of a lot of software techniques seen from an economics lens, a new take on topics such as TDD or CQS that you might’ve read about in different contexts. The third one, “Early value, low risk”, is about the process and how it relates to emerging design.
There are many great gems here and there, sometimes not what you would expect from a person with a technical background. For example, there’s one on people complaining about salespeople making “impossible requests”. What the author encourages in this case is “less complaining and more making it possible”. That’s not about accepting any kind of bullshit but about a change of mindset (which is a theme through the book). It’s about slicing the problem. It’s about focusing on the problem they’re asking to address instead of the naive solution sketch that they might have suggested and that sometimes makes us blind to what’s behind.
I wonder how much tuning would part of it require to fitting more explicitly in a startup context. For example, the book begins with a bold statement: “the goal of Business and Technology is protecting an investment”. In a startup, depending on the stage it’s at, growth or learning would be prioritized over protecting the investment. I know that the author knows, and we could probably agree through expanding the definition of “investment”, but as the topics get more complicated, the effort you require to make that translation is harder.
I definitely recommend this book to anybody who still thinks about professional software development as a sandbox isolated from business, and for anybody that feels disconnected or threatened by other areas of the company. Not only because it will help that person grow but also because it will provide tools, a shared language, that will make team work more effective (“team work” as in “we’re a team with the rest of the company”). It also works as an interesting compendium of many techniques that you might be used to, not only as a raw reminder but as a refreshing review, understanding how they relate to each other and to the business, and what’s behind the technological facade.