A Talk About Software Costs

While listening to an episode of The Laravel Podcast tonight, a talk given at Laracon EU was mentioned. The talk was given by Konstantin Kudryashov who is the creator of Behat, a behaviour-driven development framework for PHP.

The talk was a great break down on how TTD relates to the costs of creating, changing and maintaining software, as well as some testing best practices.

My favourite part of the talk is when Konstantin touches on how cost of change increases exponentially over time. He displays a piece of code and asks the audience how long they would say adding a feature would take. He then says, let's not do it now, we'll do it later. Theres something else more important. The next slide is the same piece of code but with an extra 20 lines or so, he then goes on to ask if the same feature would take the same amount of time as was just said. I found that this example really drove the point home of how as time goes on, what might have taken two days can now take a week.

Here is a link to the talk, Min-maxing Software Costs and a link to the slides.

Here are some things I wanted to pull out of the talk for myself:

Convenience based projects either die a hero or live long enough to see themselves become the villain.

  • Software Cost

    • Time to write & test code - Cost of Introduction.
      • Cost of Introduction is the time it takes to introduce new, naturally independent application logic.
      • Cheapest cost/shortest time, what people tend to focus on the most.
    • Time to change code & tests - Cost of Change.
      • Cost of Change is the time it takes to adapt the existing application logic to new business realities.
      • Cost of Change increases exponentially over time.
    • Time to refactor code & test - Cost of Ownership.
      • Cost of Ownership is the time it takes to maintain the owned application logic to support its ongoing change.
      • Cost of Ownership is the cost you pay for the right to change a particular part (module, class, method) of application continuously and sustainably. This is Testing.
      • You should pay the cost of ownership throughout the entire process so things remain maintainable. It's worth paying this up front to keep the cost of maintaining down in the future.
  • Gaming Software Costs

    • Own only the logic you need to change.
    • Write only the logic you need to own.
    • Own everything you write.
    • Try to not write anything.
    • Reuse everything else.
  • Steps

    • Document the need
    • Spike - Experiment with tools available
    • Document changes & constraints
    • Stabilize - Claim ownership when the thing grows outside of tool boundaries
    • Isolate Religiously
  • Gaming Software Costs

    1. Document
    2. Spike & Stabilise
    3. Use TDD for stabilization