This post considers some of the problems we face when creating software and then explores if reframing those issues, by using language from another domain, might lead us to new perspectives or new approaches to solving problems.
It might seem strange for a tester to be writing about economics. Moreover, this post isn’t even specifically about testing but focused on aspects of software development. I have a degree in Economics and Finance and over 20 years of experience working in the finance industry in various roles. Misuse of economics terms in software development annoys me. Return on Investment (ROI), is probably a term you have seen thrown around in testing discussions, predominantly used in discussions about automation in testing, and, often by proponents of setting up a debate in terms of humans versus computers. This is not the topic on which I plan to write but offer it as means to demonstrate the ways in which an economics/ financial term has been dragged into testing and savagely abused. There are terms we can draw from economics and finance and use them in good ways rather than forcing them to mean things they have never been intended to represent.
You might be asking “what is Economics?”. That’s a good question. Rather than re-inventing the wheel I’m going to borrow from Investopedia. It’s pretty much what every introductory text to Economics states
“Economics is a social science concerned with the production, distribution, and consumption of goods and services. It studies how individuals, businesses, governments, and nations make choices about how to allocate resources”
Personally, I would expand the above definition to include the word scarce, specifically “scarce resources.” Why “scarce?” Because everything is finite, meaning that there is an end point in supply and that supply needs to be managed.
Finance, per se, is not Economics and the reverse is also true. Economics does however help us to understand, model and explain much of the behaviour we see within Finance. There are many terms that exist within both disciplines and so if I refer to a finance or an economics term I’m using it interchangeably. I could be pedantic about this but it’s not the point of this post.
Economics can be broadly divided into two categories – macro economics and micro economics. Roughly speaking macro economics is “in the large” – countries, states and the like. Micro economics is “in the small” – think business impacts and decisions. These are (very) rough guides, ignoring a lot of important context. If you would like to know more I’d encourage you to dive into some reading. This blog is going to talk at the micro level.
If I use the terms “supply” and demand” my guess is that you could understand them in ways that are relevant to economics discussions. Heck you probably talk about these concepts often without even realising it. “Wow, fruit is getting expensive because of the drought impact” (supply related)” or if you lived in Melbourne during lockdown you might have stated “petrol is really cheap with people not driving anywhere” (demand related). There are many ways I could twist these examples to show different outcomes but the above is enough for now.
Think about your workplace, see if you can come up with the commodity that is likely the most scarce resource. In my world it’s time. There is limited time available in any given day, week, sprint, however you wish to divide your time. Now think about the demand side of time. It’s near limitless, right? How many times have you been in discussions at work and actually considered how you are balancing the commodity of time? I have no doubt that some people reading this might also be wondering about money. Of course money is important, and it too is subject to supply and demand forces, but if you manage your money well and your time poorly the cash will eventually run dry. The sweet spot is the “equilibrium point”. That is the point where the demand and supply of commodities are balanced. There is no excess demand or excess supply. How many companies discuss time in terms of equilibrium rather than playing some strange game where they believe more time can be produced?
Opportunity cost is quite simple. I have to make choices, I can’t have everything so for example, if I decide to buy a new luxury car I’m going to have to forsake that around the world trip I would like to do. So, in short, I can have A or B, but not both. The opportunity cost of acquiring A is B and vice versa. What if we tried rephrasing some our project decisions to be explicitly framed within “opportunity cost”? When we do this we need to understand value – both to ourselves and our customers. If we consider our major constraints – time and money – we need to make choices about what we deliver. What is the highest value to our customers, how much time do we have available? We could do projects A, B and C but the opportunity cost is projects D, E and F. Damn it, we really need F. OK we can do F but the opportunity cost increases as we cannot complete projects B and C. But A is really important – we need that. Sound familiar? I’ll bet you’ve been involved in conversations just like it. Within these constraints we have a spectrum of possibilities, we have options. Those options range from do none of the projects to do all of them (the time constraint should tell us that “do them all” is probably a really bad idea). Each of those choices also has an opportunity cost attached (how valuable is your reputation, what is it worth?). Value figures in our opportunity cost ponderings. The smart play is to figure what we can deliver, that is valuable, and within our constraints. We still have an opportunity cost but that’s (probably) unavoidable.
Let’s consider risk. If you work in software development risk is a term you’ll be very familiar with. It’s also a finance term. There is a rule in finance that says “the greater the return, the higher the risk”. For each increment up in risk, investors expect higher returns to compensate for that risk. Likewise at lower levels of risk the returns are generally lower and returns will ratchet down as risk reduces. Lack of risk = safety, you don’t really get rewarded (with high returns) by playing it safe. There’s another important aspect in this – sensitivity to risk. If you have a big bunch of money (Bill Gates style big bunch) then you might think nothing of investing a million dollars in an investment and hope that your get twenty million back in twelve months. If the investment fails, probably no big deal. This is a low sensitivity to risk. If a million dollars represents all your assets plus some borrowings your sensitivity to the risk of losing all or some of your wealth is likely to be quite (extremely) high (you’d be risk adverse in this context).
How often at work do we talk about risk in terms of returns as well as our sensitivity to risk? When we create a project we have multiple risks, they change during the project, they change after delivery, they change during post delivery maintenance. Would I be too far wrong if I suggested many discussions around risk are confined to a matrix where we , almost randomly, assign values against likelihood and impact and we spend little, if any time, contemplating post delivery risk? If we consider returns in terms of business satisfaction through the delivery of value, I suggest that if we replaced our “risk matrix monologue” with discussions about how risks relate to returns, we would produce better understanding of important risks. What if we inspected each of these using the lens of “sensitivity”? Does that help us understand what risks might really be important to both the company and its customers?
Not all risks are equal (even the matrix approach tells us this). If we can recognise this then we can start to stratify those risks using sensitivity. We can accept that some risks, even if realised, may result in very little inconvenience for our company or our customers. As an example we decide to change the font used for field labels in the GUI and we release quickly to production. Our customers, post release, report that not all fields have been updated to the new font. Not great, sure, but we could live with this. In fact we could be so insensitive to the issue that we don’t even prioritise fixing the inconsistency. Now consider a major release to our product, a significant upgrade. We have assessed that the upgrade provides considerable value to our customers, and have advertised this upgrade aggressively. We operate in a competitor rich environment and if the upgrade fails in any of the key functionalities our customers use, or any of the new functions, the company could suffer considerable customer and reputation loss. In this scenario we would likely be much more sensitive to the impacts of risk and we would be very diligent in our approach to finding and mitigating risk. We might even decide to release these changes in a series of slices so we can avoid a risky “big bang” release and to allow us to gather useful feedback on each small release.
What I have outlined in this post is very high level but hopefully enough for you to understand that reframing problems, through the language of other disciplines, can help us gather new insights. I have selected a couple of terms that seemed particularly useful, I could, and might, pick a few more in a future post. Using the language of economics and finance might not appeal to you, it might not feel comfortable for you to use it. You could instead choose to find inspiration in another discipline where the language is comfortable for you. If you choose not to reframe in the ways I’ve discussed, in making that choice you have thought about how you currently frame problems and why you are happy with what you are doing. Either way, your self reflection is a growth tool and, if this post contributes to your growth, I can’t ask for more.
Thanks to Lee Hawkins (@therockertester), Lisa Crispin (@lisacrispin) and Janet Gregory (@janetgregoryca) for their reviews and very helpful feedback.
@Beaglesays 
2 thoughts on “some Economics of software”