Can Quality Hurt Software Projects?

Can quality hurt software projects?

I recently had the pleasure of interviewing 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 specializing in helping others learn how to craft clean code. Carlos has been very active as an international speaker and is a contributor to the Agile Spain community.

Carlos began the interview by 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 create 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 businesses, so on-time quality products can be delivered by software crafters who are really proud of their work.

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

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks
Juan Banda

Juan Banda

Juan es un capacitador, expositor y pensador alternativo. Desde que Juan se expuso a Scrum a principios del 2007 se comprometió a continuar aprendiendo y aplicando Scrum en los equipos y organizaciones donde trabajo. Su camino lo ha puesto en los roles de ScrumMaster, Scrum Trainer, y Product Owner. Juan cumplió el 2014 con todos los requisitos del Scrum Alliance para ser un Certified Scrum Trainer® (CST) y es ademas un LeSS Friendly Scrum Trainer.…

Recent Agile Alliance Blog Posts

Post your comments or questions

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now