The “real” costs of developing using agile methods

What is "money", really?

Have you considered what goes into all the agile disciplines we love and espouse?

Though I missed last Monday’s post due to Independence Day, it’s time to come back to the economics thread.

If you want to catch up, these are the first two posts:

  1. Mankiw’s “10 Principles of Economics” and information technology
  2. Principles of IT and software à la Mankiw (which includes the first principle, “People face trade-offs“)

The second of Greg Mankiw’s fundamental economic principles is:

The cost of something is what you give up to get it.

Costs, expenses and money in software development

First, my simple distinction between expenses and costs is that expenses deal with consumption and costs deal with investment.

When we bear expenses, they are for one-time use of a resource. When we accept costs, they give us access to assets.

So from a financial accounting perspective, we refer to the “cost of goods sold” (which generate gross profits) and we refer to “general and administrative expense” (which keeps the lights on and the bills paid).

Now, we most often think of expenses and costs in terms of “money”, or more appropriately, “currency”. Currency is what we often use in transaction, but we can use other things as well. So “money” in economic terms does not refer only to currency, but to any capacity that we have to transact.

So we can speak of “costs” in terms of time, money (including currency), energy and other lost opportunities. As an investment, we would want to trade those costs for something we decide is worth it.

Have you ever gone into a marathon meeting with a dozen people and wondered how much the meeting was costing for those endless hours of indecision?

What you give up to get it

I use the term “budget” during the planning games of my projects, to refer to how much effort we plan to expend in a given release or iteration, based on a rolling team velocity and the duration of the coming iteration. The budget sets constraints on the “costs” we can bear in terms of the effort available to the iteration.

We work with our customers in planning what we can do during that time interval, and  trade-offs (principle #1) and costs (principle #2) confront us almost immediately. We can’t add hours to a day or days to a week, but we must get real work done in the time we have.

We have limited resources at our disposal, and a choice to include one feature in the iteration involves a choice NOT to include some other feature. We consume all the time, energy and money required to complete the first feature, which is no longer available for working on some other feature at the same time. The first feature better be worth it.

During development, a choice to diverge from plan due to a critical shift in priorities produces a cost of shifting the coordination of perhaps the whole team… and the cost is not zero in terms of the impact to the project.

The cost of multiple, rapid context switches by developers is also real, so if a team cannot keep up direction and focus or if a customer cannot set priorities or produce consistent and reliable requirements, there is a cost that is real… and better be worth it.

What other costs can you think of in process of writing software? What opportunity costs come to mind? Do you think they are always accounted for? What about agile principles and the cost of following (or not following) them?


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.