#01 We are business

Software economics book resources

Sorry for the mess! This version is just a first draft ;-)

Términos a googlear

Kent Beck, modern agile, extreme programming, time value money, economía de escala, real options, technical debt, refactoring, scrum, kanban, waterfall, agile, risk assumption test, minimun viable product, cynefin, value stream, cuello de botella…


Coding Horror:paying-down-your-technical-debt

Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future. If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets accumulated technical debt becomes a major disincentive to work on a project.

Martin Fowler:TechnicalDebt

Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The biggest cost of technical debt is the fact that it slows your ability to deliver future features

About refactoring

Risk of Introducing Bugs (not caught by testing) Cost and Risk of Refactoring tend to be low, as we have good UnitTests. Also the “size” of refactorings tends to be smaller Adding new features no longer corrupts the system’s structure Optimizing the maintenance process to minimize the visible changes to the source code must, as with any optimization, compromise something else Improves programmer’s understanding of the system Refactoring produces shorter simpler methods. It’s less work to understand the smaller amount of code that needs to be changed to implement any given function

Coding as team activity by Xavi Gost

  • programar es una actividad de equipo. Una persona sola no puede hacer nada que tenga impacto
  • se supone que me pagan para dejar allí conocimiento
  • consenso es estar de acuerdo en este momento para hacer esto concreto
  • pair programming extenuante. También hay que tener tareas solas
  • en el panel apuntar concerns: “qué mierda me ha hecho angelito”. No le molesto en el momento. Los concerns no los voy a dejar pasar… pero los atacaré en la review. La decisión la toman todos los que tienen que vivir con la decisión
  • los argumentos tienen que estar razonados

Scrum y la gestión del riesgo

  • (link)

  • ampliación descontrolada de características

  • captura de requisitos mal realizada

  • calidad insuficiente

  • plazos optimistas impuestos

  • diseño inadecuado

  • síndrome de desarrollo orientado a la investigación

  • personalinadecuado

  • fallos de los proveedores

  • fricción con los clientes

RAT: Riskiest Asumpting Test vs MVP Minimun Valuable Product

  • (link)

  • MVP is not a product. Developing a production-ready product is more than that.

  • Maximize discovery

[Agile Architecture, Risk-driven]

  • (link)

  • Identify and prioritize risks

  • Select and apply a set of techniques

  • Evaluate risk reduction

Designing early customer learning

  • (link)

  • How to test assumptions and reduce risk, quickly

  • Start by clarifying your learning goals, assumptions, and hypotheses

  • Prioritize assumptions on two dimensions: uncertainty and risk

  • Make your assumptions testable

  • Ask yourself: What is the smallest thing we can do to test this hypothesis?

  • Create the “learning vehicle”

Evolutionary agility

  • (link)

  • Real agility is awesome at managing risk.

  • You cannot be agile if you don’t actively manage your risks.

A case for outside in development

From system to DDD: better risk management (architecture)

The Cost Center Trap (Poppendieck)


  • every ‘full stack team’ working on a digital problem should have ‘full stack responsibility’ for results,
  • very few of those agile teams are likely to focus on improving overall business performance. The incentives send a clear message: business performance is not the responsibility of a cost center.
  • capitalization of development creates a hidden a bias toward large projects over incremental delivery, making it difficult to look favorably upon agile practices.
  • customer obsession, a skeptical view of proxies

Cost accounting is a problem in the knowledge work


  • Software is neither construction nor manufacturing. Software is learning, where we deliver learning as pieces of finished product. When we have finished learning enough for now, we stop working on the deliverable.
  • That would reduce the cost per feature. Smaller features allows us to learn faster and see value faster.
  • Cost accounting has a big problem. It does not account for Cost of Delay
  • There are alternatives to cost accounting: throughput accounting and lean accounting.

Nat pryce y steve freeman sobre tech debt

The great thing about Ward’s original concept was making explicit that we can trade off short- vs long-term. Like making Refactoring a thing. And giving us a mechanism to do so with iterative development. It was never a licence for rushed hackery. Indeed. My understanding of Ward’s metaphor was that tech debt was what ENABLED iterative development, not something to be avoided. but the meaning changed over time, until it became as on the tech debt conf website. Along the way, a powerful tool was lost. I guess. I was put off by “…can make future changes more costly or impossible”. To me, tech debt is what allows future changes at all. And I’ve been using “tech underinvestment” for code becoming too costly to change.


Real Options

About Technical Debt

About refactoring

Coding as team activity by Xavi Gost

Architecture as risk management

Scrum and risk management:

Agile is not faster



agile is optimized for complex world