Software development, facts and quality: A lack of proof?
I think that Software Development and Quality is a fascinating subject. It concerns the analysis of tools and practices which improve productivity. This week, I checked an article from Greg Wilson about Software Development and its comparison with the medicine world.
The article explains the lack of evidence base in the Software development world. When we need to prove something in the medical world, we use studies. In the Software world, there are plain of “headlines”, "punchlines" and "tags" without any proof:
- DRY: Don’t Repeat Yourself.
- KISS: Keep It Simple, Stupid
- YAGNI: You Aren’t Gonna Need It.
- And others
Those claims were emitted by the most brilliant guys in our industry, from merited books or academic journals. However, they are not accompanied by any citation or studies.
In a medical context, Those facts are “Not proven” and would not be “applied” to concrete treatment. Some developers use those beliefs on not proven facts: The base is fragile and could be destroyed by a study.
Of course, these facts are “intuitive” and looks like a great way to improve the code base. In my case, I believe that SOLID principles, DRY and others are a significant “landmark” to drive my coding style. However, they are not linked with proved data. Moreover, some of them are misquoted, as explained in the article by Greg Wilson on quote “The best programmers are up to 28 times more productive than the worst”.
One example of proven/not proven data: Test-Driven Development.
Featured by some developers as the “magical pill”, TDD is also a practice with unwillingness for many reasons:
- TDD requires the skill to write “Good” and “Short” tests.
- Without proof, nobody wants to put effort into it. Do TDD worth it?
Fortunately, TDD is the subject of many recent studies. They are proof of the benefits and disadvantages of TDD. Without using “tags”, they are a weapon to convince developers and managers about “the goods and evils “of TDD.
For those who do not know what TDD is, I will simplify the definition. It is the process to write the test before the development of a feature. Those short tests are in the “Green Red Refactor” cycle:
- Write “Failing” test – RED - FAILED
- Write minimal code to pass those tests – GREEN - SUCCEED
- Refactor the code – REFACTOR
- Re-run the test to pass it GREEN, and restart the process with another minimal feature.
Thanks to this process, TDD allows tests to guide the implementation to maintain a supposed “higher-quality” code. Even if it is not yet proven, multiple studies are in progress about the benefits and disadvantages of TDD!
Some of them claim that TDD improves productivity, other that it decreases productivity. Sometimes it depends on the industry. Maybe, it depends on the project size or other!
But overall, in the industry world, current studies show that TDD improves quality, bug count and improves productivity in the long term (when it decreases short time). This kind of evidence is a weapon to convince you to embrace or not the TDD development style.
As you see, the Software world is full of claimed facts. Some developers will feature those claims as a “quality elixir”. I do not think it is an excellent way to improve the software world. Some leaders force the introductions of those facts, which add tensions, without guarantee of quality.
I keep in mind those headlines to guide my own “coding style”, but not to force a complete team without agreements.