Can Quality Hurt Software Projects?

Added to Process

I recently had the pleasure to interview Carlos Blé from the Canary Islands in Spain.


Carlos is a software crafter with almost two decades of experience in software development and has been involved with the Software Craftsmanship community for more than a decade. Carlos is also a consultant and software mentor and has his own company specialized in helping others to learn how to craft clean code. Carlos has been very active as an international speaker and is a contributor in the Agile Spain community.

Carlos began the interview mentioning that eXtreme Programming has been a turning point in his career as a developer, because before discovering XP he used to program without a formal mental model or process. He mentioned that XP provides a method that leads to homogeneous results and reduces long pizza nights and elevated stress before a release. Furthermore, XP in his view helped him to have predictability, a sustainable pace, and craft good quality software.

In Carlos’s experience, automated tests are undoubtedly a great contribution to overall product quality. In his opinion we humans are very good at introducing defects into code — it’s just part of our nature — but XP practices like Test Driven Development (TDD) help creating tests that catch those defects. Carlos also mentioned that is not just one type of test we need; instead we should aim for a good combination of unit, integration, end-to-end, and other types of tests. A common denominator for these tests is that they are automated and provide rapid feedback.

When Carlos is coding he is not using the debugger, he said. Instead he introduces unit tests that alert him when something is broken. Unit tests also enable him to partially, effectively, and quickly test sections of the product.

Carlos mentioned that for him TDD is a practice for crafting code in small increments. Carlos sees TDD as a protocol that, when followed, leads to quality in the form of clean code and good automated tests. Also, in his opinion, TDD is not the only way to create code with good code test coverage as he has seen teams that produced good tests and excellent test coverage but didn’t use TDD for that purpose.

TDD, according to Carlos, can help with functional requirements — but for non-functional ones we’ll need to look for something else. TDD as method for emerging design used in isolation will fall short because it doesn’t touch on things such as software quality attributes, Carlos said. Notwithstanding, doing TDD is much better than just coding with no protocol at all.

Speaking of Pair Programming, Carlos stated that he has never seen a product that suffers in time or budget because two developers coded in pairs. In actuality, he said, Pair Programming hasn’t produced any bottlenecks. Instead, it reduced accidental software complexity that comes for over-engineered thinking. Furthermore, developers coding in pairs end up writing less and cleaner code.

In his view, companies are not looking clearly at Pair Programming because of their short-sighted vision and because they lack developers who actually know how to do this practice well. To reinforce his point, Carlos mentioned that developers spend an awful lot of time reading code that they don’t understand. Cleaner code created in pairs is a known solution to this problem. In Carlos’s words, the problem in software development has never been how fast developers can type, but how they can reduce accidental complexity.

In closing, Carlos shared an important reflection: dogmatism inside the software craftsmanship community could hurt software projects if the obsession for quality trumps pragmatism. He called for getting back to the origins of the software craftsmanship movement and reducing the breach between developers and business, so on-time quality products can be delivered by software crafters who are really proud of their work.


About the Author


Juan se especializa en entrenar, mentorear y hacer coaching de equipos Agiles para que en corto tiempo puedan alcanzar resultados asombrosos. Juan es también un agente de cambio que ayuda a que empresas completas vuelquen sus prácticas hacia formas más humanas de trabajo. Juan es un Certified Scrum Trainer (CST) y LeSS Friendly Scrum Trainer. Su formación universitaria incluye un grado de Magister en Administración de Sistemas de Información conferido por The University of Illinois at Chicago.


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.