Take your time to pay for this technical debt, but let me know how you would prevent it in the future!

In a previous blog, I explained why 'Technical debt is not bad!', and explained that this idea pays for itself on the long run. However, the title of this post indicates the right question asked by senior management while negotiating time to pay for technical debts.

The idea is that: Part of fixing a problem is preventing it from re-occurring.

This does not mean that technical debt will not re-occur; it means that the specific issue that caused this type of technical debt should be resolved from the roots and hopefully not re-occur.

This way of thinking is a characteristic of high mature organizations.

Technical debt is not bad!

Technical debt is usually thought of as a notorious thing indicating bad (or no) design, and leads to projects failure after several iterations.

Actually, this is not true. Refactoring is a constant effort done by the development team even with the most intelligent designs. Developers (and their designs) matures "while" working on the project. This maturity emerges from that following facts:

• The level of understanding of the business domain gets clearer.
• Seeing the design at work develops more brighter design ideas.
• Development work is the most effective learning experience for developers. So, the more you develop, the more you learn about design concepts, and the more you see opportunities for improving the existing design.

This is why teams should find a way to incorporate paying technical debt every now and then. By incorporate, I mean to reflect on it as part of every iteration, or may be dedicate an entire iteration for it if needed.

Software Development does not follow any predictable manufacturing process rules

In this excellent presentation about Agile Estimation, by Christoph Steindl. The author lists the difference between what is called "Predictable Manufacturing" vs. "New Product Development". These differences are following Lean principles, and applies to any endeavor.

Reflecting on these differences, it is so clear that Software Development does not following the rules of Predictable Manufacturing defined processes. This is because Software Development is an innovative, intellectual, and usually creative effort that cannot be govered or managed by any strictly defined process. True!

Something came to my mind while reading this, which is how to improve both types of processes.

For any defined process (predictable manufacturing), it is improved by getting it more and more defined to account for new special cases, or new causes for variation.

For any empirical process (new product development), it is improved by enhancing the feedback control system, which steers the development effort, and upon which everyone in the development team should depend.

Imagine what would happen if software is developed without such feedback control system?

In a next blog, I will give examples of famous mechanisms which implements these feedback control systems in software development.