Can We Write Good Quality Software Faster?
(photo by kakaopor)
Steve from Ardalis.com wrote an interesting article that discuss about the internal and external software quality. He defines external quality as the software’s presentation and behavior from a user or customer’s perspective, such as, bugs, UI, input validations, etc. While internal quality refers to to how the software was constructed, and how easy it might be to maintain or extend.
So, external quality is the quality that can be appreciated by everyone, while internal quality is the code beauty that can only be appreciated by developers, and here we focus on the latter.
He proceeds to discuss that virtually all of the software codes created today is of relatively poor internal quality, and this is largely due to the capabilities of the developers in the development team, unappreciation to code quality, and lack of time to write good quality code.
An interesting discussion is presented when he refers to an article by Robert Martin that argues that a good quality code using TDD don’t take long to write, and in fact are actually faster to write compared to low quality code without TDD when the developers are used to it.
The complete article can be found here.
My Response
The article hit right on to the most common reason of why some software codes are bad, and that is the time constraint. From few years of experience, I can attest that this is the ‘excuse’, if not reason, why managers allow this to happen. There is always not enough time to do all the best practices that are actually known by development team, and thus shortcuts are allowed as long as the closest deadline can be achieved. Those things can always get fixed later on in the next versions when there are more time.
The problem is, that ‘time’ rarely comes.
New requirements, new technologies, change of team members, and of course, new deadline. All of these seems to coinspire to make everyone forget about the low quality parts of the system that becomes the system’s weakest link and need to be taken care of.
Does writing high quality code can be fast?
Short answer, it depends. Long answer, read on.
The article took Uncle Bob’s example of writing high quality code as using TDD (test driven development). It argues that after ‘flipping our bit’ or changing our paradigm, using TDD is actually can be faster than not using TDD.
A bit of side note, I don’t believe using TDD is equal to high quality code. The code is generally faster to extend because of available unit tests that can do fast checking of code functionality in terms of input and output. But, the good code design and implementation is not guaranteed.
Furthermore, uncle Bob mentioned that he successfully write better code faster by using TDD for a month or so. This sounds too optimistic for me.
Writing good code takes knowledge, discipline, practice, and time (certainly not just one month or so).
I agree that the best programmers (the Ninja, the rock star, the guru, or any other cool title) can write great codes in a lot less time than the average ones. This is largely due to their years of experience, and some people really possess that talent to write beautiful piece of code.
But, if we need to compare the time required for these programmers to write codes with and without TDD, I would say that the latter will consume more time.
TDD Experience in PDP
The first time I read about this article, static testing method comes to my mind, it’s “Code Review” or “Code Walkthrough”. I personally experience this in my first semester when I’m taking the “Program Design Paradigm” course a.k.a. “The Bootcamp”. The course enforced us to write tests for each function and also present (and defend) our code for every week’s assignment.
Was it faster? Not when we’re writing the code, but certainly when debugging.
Was the code of high quality? It depends.
Why wasn’t it faster?
From the common sense point of view, writing tests means writing more code. Assuming that the function requires only 10 lines, and the test may take 50 lines or more, obviously writing these tests takes more time.
These tests will save more time when the software gets more complex, continued by different developers, or needs to be changed some time after they were written.
Not writing the tests can be considered as technical debt, and just as the financial debt, the more they accumulate the greater the disaster will be when they due.
Why the code was not necessarily of high quality?
Having tests and passing them doesn’t automatically justifies that our code is of high quality. Passing tests means that the code works and (hopefully with enough test cases) able to handle some cases with invalid inputs and possible cases.
What happens in the middle require more than tests.
Well, we can use tools that automatically enforce preset code standard and formatting, such as Checkstyle for Java. However, this is still limited to syntax and code checking, it cannot detect low quality design.
So, another possible solution is to do the manual code review, unfortunately this takes more time.
So, is the myth busted?
Honestly, I’m very skeptical when Robert says that writing a good quality code using TDD can be faster than writing a poor quality code, especially if it’s on a greenfield project, provided that the developers skill are equal.
I think the time required to write either good (without tests) or bad quality code are more or less the same, so writing tests will definitely require extra time (albeit very well spent).
But if you ask me if do I agree that writing good quality code can save time in the long run? Definitely!
In the end, I agree that stakeholders need to be concern about the code internal quality. As software becomes part of our lives and also business’s, investing in having good quality code means investing in the long term continuity of an organization. In the fast-changing and competitive world that we live in now, this can make a great difference. 🙂
Resources:
http://en.wikipedia.org/wiki/Technical_debt
http://en.wikipedia.org/wiki/Greenfield_project
http://en.wikipedia.org/wiki/Checkstyle