When I got started as a professional software developer, I thought awesomeness in development was measured by the lines of code (LOC) per day and how quickly code got to QA for testing. Coding a few thousand lines overnight gave one instant bragging rights, regardless of how well the code worked (or didn’t) in the morning. The more senior guys always acted like they knew better, suggesting that it’s not about the quantity but the quality. But I was too young and arrogant to listen. And, of course, I had to learn it the hard way. My seemingly amazing overnight code would show cracks once under the microscope of the QA team.
True today as it was then, most mistakes are tiny and easy to fix, but even small problems require a tedious set of steps from when a QA engineer finds the mistakes to when the developer fixes them and sends them back to QA for verification. Some bugs are the size of the Mariana trench and require weeks of work and thousands of additional LOC. And, even new code, once resubjected to QA, can generate bugs, therefore repeating the cycle without an end in sight. Of course, by this time projects are late and developers are tired, frustrated and burnt out.
After this happened to me too many times, I realized that maybe I was wrong. Maybe the experienced guys were on to something with this quality thing. They never seemed too tired, and their projects were in much better shape. I decided that for my next feature, delivering quality instead of LOC would be my priority.
I’m sure you think you know what’s coming next. I’m going tell you that I tested my stuff from that day on and it worked perfectly—no more boring bug-fixing. You think I’m going to tell you, you should do it too, right? Well, no. I actually spent a lot of time in my second attempt instrumenting my code better so that I could debug it faster as the need arose. I also spent a lot of time writing my own test tools because I didn’t have one. But I kept moving forward and learned the hard way. Here is what I took away from those moments:
Develop More, Bug-Fix Less
There are two common reasons for developers’ involvement in a project. Developing a new feature or enhancement is about creativity, as it gives one the opportunity to design and implement new things. And then there’s the challenge of bug-fixing, which is all about maintaining existing functionality within older, already-made things. As a developer needs to do both, often at the same time, minimizing bug-fixing time is important to have more time in which to actually be creative and develop new functionality. And the best way to minimize bug-fixing is to test code more, as it’s developed, to avoid the death spiral I describe above. Good initial quality will mean QA will find fewer bugs and it is very likely that the criticality of the bugs found will be greatly reduced. As such, fixes no longer would be a struggle on short notice; shortcuts that generate more bugs don’t have to be used; and developers can focus on new features as opposed to fixing bugs. In all, the reasons are to develop more, and bug-fix less to be more productive.
Be More Reliable
Bugs also are nasty in that they tend to appear really, really late in the game. The Murphy’s Law on bugs should be something like, “The hardest bug is found one hour before the release is pushed to production.” This typically happens because everyone is busy peeling the onion, finding and fixing bug after bug until they get the “system” stable enough for QA to crush it with those large-scale system test cases that expose that one nasty bug. It is an artifact of waterfall development but also happens in agile development, as no agile team can afford running long duration tests in a sprint. So what happens then? Who ends up in crunch mode? The developer. To avoid this, developers need to find and fix the easier bugs sooner, as they write the code. That way, the onion is half peeled once it reaches the QA team. The nasty bug will be found much sooner—if the developer did not find it and fix it already. In short, developers can be more reliable by avoiding last minute bug-fixing. And we all know, reliability in execution is fundamental for fostering trust with management. A trusted developer is the one that gets to work on important, meaningful projects.
Be More Flexible
While in an ideal world the design of a feature is not changed frequently, in real life the exact opposite is true. At some point, even regularly, developers will have to modify the code as the scope of the features keeps changing. Massive code changes such as refactoring, if not done right, can send developers right back to a long, teeth-grinding, bug-fixing period. Avoiding it by testing early, as they change the code, offers a significant advantage—flexibility. Developers would be able to accommodate required changes more quickly.
Agile Development is Critical
Let’s do a quick recap: By simply testing code as it is written, developers can spend less time fixing bugs and more time developing new features, to become more productive, more reliable and trustworthy and even more flexible in implementing changes. This takes us to our final reason for early testing: Agile development is no longer nice to have, but business-critical. All of the attributes described above are quintessential for succeeding in an agile team. Developers are expected to be flexible, reliable and build a lot in short time periods. The days of trial and error, of learning the hard way, are gone. Today, we need to go from design to development to testing to going live in days, not months. Quality is what differentiates products. Developers need to do all of this to be successful.
About the Author/Gabriel Chiriacescu
Gabriel Chiriacescu is the director of Software Development at Ixia, with more than 13 years of experience in embedded software development. He is currently leading the product management effort for the new Ixia Developer solution, an agile test tool designed specifically for developers.
At Ixia, Gabriel has led multiple engineering teams responsible for developing market-leading test solutions in a variety of technological areas, including wireless, broadband access, data center, triple play, authentication and security.
A native of Bucharest, Romania, Gabriel holds a BS in computer science from the Polytechnic University of Bucharest. After living several years in Los Angeles, Gabriel is now based in North Carolina and enjoys discussing CICD, SOA design patterns and the evolution of software development.
