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 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.

Como CST y LeSS Friendly Scrum Trainer Juan ha entrenado a más de cuatro mil trescientos estudiantes en cursos de CLB, CSM, CSPO. A-CSM y A-CSPO en diez países del continente americano. Juan también a dado cursos privados para compañías como: Citibanamex, Marsh, Slalom, Deloitte, Walmart, CGI, SAIC, Express Scripts, T.Rowe Price, Time Warner Cable, ViaSat, Garmin, Moffitt, Kyva Systems, Blue Book Network, Insurance Auto Auctions and BlueCross BlueShield.

Juan fue miembro voluntario del Board de Directores del Agile Alliance donde sirvió por dos periodos consecutivos de tres años hasta el 2019.

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.