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