Principles of IT and software a la Mankiw

An economy IN software, or the economy OF software?

What does economics have to do with software anyway?

Having run a quick check, there are 14,501 hits on Amazon related to “software economics” and 14,001 related to “information technology economics”, as of the day of this post.

So what new territory could we cover in this series?

With all the writing about economics in software and IT, you would think its core tenets would work their way into our everyday speaking… but I don’t really notice them, do you?

Given 10 fundamental principles of economics, we could take this thread one of two directions with its second post:

  1. Come up with yet another list of principles of economics for IT, which has obviously been done
  2. Consider the ways that those ten principles show up in IT and software

It was the second path that made me think this series could be worthwhile. Each week we will go deeper into each, and they will get much more detailed as we go forward. We start simply this week, though.

Back to the distinction for economics, “the science that deals with the production, distribution, and consumption of goods and services…” we might adapt it to say more simply that economics is the study of transactions or the study of how we transact.

To me, the study of how we transact with each other, engage with each other, make and fulfill promises to each other, sounds a lot like software production and the day-to-day function of an information technology organization.

Consider the first principle, and maybe the easiest to discuss:

People face trade-offs.

That sounds simple enough.

There are many common trade-offs cited in the production of software – speed vs. time vs. quality, scope vs. time vs. cost, etc.

Here are some trade-offs we might not think about often:

  1. Every minute we spend learning one new technology we are not spending learning another one
  2. Every minute we spend maintaining broken software requirements we are not spending writing new valuable features

Trade-offs are not about what is right or wrong… they are just trade-offs. We all have scarce time, energy, money and opportunities… and opening one door closes others.

There are many, many ways we face trade-offs: sometimes within teams, when budgeting, when managing and even in actions like attending a conference or a golf outing… Mankiw’s first fundamental economic principle applied to our domain.

If this post triggers you to think of any, please offer your favorites to the community in the comments below.

About ken
Creative insights, passion and technical adrenaline - strategist, agile coach and marketer, providing a good life for wife of 20 years & 2 awesome teenagers!

4 Responses to Principles of IT and software a la Mankiw

  1. Rick Ross says:

    Here’s one for you. Every minute we spend training, teaching or helping other people we are unable to work on other things.

    That being said, I view helping, teaching and/or training people to be an investment that has a potential for producing valuable future returns.

    • ken says:

      I accept. On the one hand, we can say any minute we spend on one thing we cannot spend on another thing… in the trade-off area, I wonder if it might not be even more illustrative to compare the time we could have spent training, teaching or helping someone else to the time it might take us to do something ourselves?

      This is a choice I see people make all the time… sometimes beyond their capacities.

      Consider in an agile team the trade-off between writing some service integration yourself or allowing someone new to the team to struggle with it, look things up and maybe even ask for help or guidance… under schedule pressure you might be inclined to do it yourself, but without that pressure you may leave room for the “training opportunity”.

      Can you think of other trade-offs in the design of projects, the choice of architecture or the allocation of resources?

  2. Pingback: A fourth rule for agile project managers «

  3. Pingback: The “real” costs of developing using agile methods «

%d bloggers like this: