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?

Who struggles embracing unit testing?

Will unit testing "come back and slap us in the face?"

Today I want to share with you a blog post that I just loved reading over the weekend: “Why bother writing unit tests?” by Justin J. Moses.

Take a minute and jump to it… and then we can come back and talk a little more about what you have just read. (Go ahead… I’ll wait here.)

Thanks for coming back! First, let me start by saying I love hearing someone else’s history with unit tests.

The energy that Justin showed in writing about kicking and fighting his way into becoming an advocate for unit tests teaches me a lot about what people experience in adopting a new approach like unit testing.

A different story of unit testing

In the mid-90’s, in the advent of Java in the browser (think applets and Netscape Communicator), I was working as a consultant integrating testing methods into the development life cycle for Chrysler Corporation as part of their QS9000 standards initiative.

A colleague and I were building a software testing and certification lab, buying & developing custom tools for registering and certifying apps and designing processes for better requirements, traceability, regression, scale and load testing.

We had lots of toys to play with, but the one idea that resonated with me most during this period was that business requirements were getting transformed too many times before software delivery.

If anything could help us write better software it would be reducing those transformations and knowing that we ultimately tested what we wrote and that we wrote what our customer wants. Simple enough, right?

(By the way, across the cube wall from us was another little Smalltalk project for the Chrysler payroll folks… but that’s a story for another time… and perhaps one of the reasons I lean more toward XP… again, a story for another time.)

Some of the side effects of Test-Driven Development

So Test-Driven Development solved many problems for me. Closer linkage of requirements to tests, and the suggestion that if we preserve that linkage and stick to the scope of our tests… some really great side effects can show up for us, like:

  1. No gold-plating
  2. Successively refined coding, and not out of control
  3. Simpler code
  4. A discipline that supports true continuous integration (CI)
  5. Test failures (with rigorous CI) offer a laser-focus on what changed & who worked on it over a short time interval
  6. (and probably many more)

If the bar is green, the code is clean?

And with the release of xUnit frameworks to support building and automating tests it seemed to me like the answer to prayer! So I went into TDD and CI head-first, and therefore it’s good for me to carefully read and understand that not everybody has the same experience.

I make TDD and CI a requirement of my teams, among other practices… and so an understanding of the struggles people can face is also important if we’re all going to produce and write great software together.

What was your experience embracing unit testing… more like Justin’s or more like mine? Have you tried TDD or CI (not just an automated build/test process)? What struggles have you had? How did you cope with them?