Does Quality Software Code Really Matter?

Monday Sep 14th 2009 by Eric Spiegel
Share:

Taking steps to prevent bugs and unnecessary code complexity can sidestep tomorrow's maintenance headache. Why is it such a low priority?

This is a waste of time.”

Our most senior programmer, Trey, was glaring at me across the conference room table, with a trace of desperation in his voice. I was explaining to our team that we were going to start doing peer reviews of code and unit testing results before they could submit their work for quality assurance testing.

Trey was expressing his displeasure with this decision, stating that if his code worked, then why should anyone care about what is under the hood?

This conversation took place a few years ago, but it still sticks in my memory because I’m a stickler for following standards and for well documented code. Having inherited poorly written code, I can empathize with the programmers who have to deal with crappy legacy code.

And guess what, even if it works, it can still be crappy. That’s because if something changes in the environment to cause that code to stop working or there are enhancements needed, some poor sap will have to figure out what planet the initial coder was on.

So I started to wonder what software is available to automate the process of writing more efficient code that reduces testing time and overall maintenance costs. Such software does exist, so the real question is: why hasn’t it become more prevalent?

Agitar Software came to mind because they plowed through over $30 million in venture investments. According to their web site -- which is still operational, although their assets were purchased by McCabe -- their Agitator product “helps developers understand the behavior of their code as they write it.”

The idea is to help prevent bugs and unnecessary code complexity that can become tomorrow's maintenance headache.

Sounds good to me! And there are many other software firms with similar products on the market like Cast Software and Codign.

But I had to do many variations of Google searches on “software quality tools” to even find a few decent examples. Noticeably absent were the usual slew of Google adwords. I did find a decent blog by Andrew Glover that had a major focus on this topic, but otherwise it was slim pickings.

So why isn’t there more of a market for measuring and improving the quality of code?

From a developer’s perspective, you want to get the job done in the expected timeframe. Of course you don’t want your code to blow up in testing. But how important is the quality and maintainability of the code?

Let’s face it; these metrics aren’t high on the list of today’s overburdened developer. That is – unless it is made a priority by management.

If a developer knows that their annual reviews will take into consideration the quality of code based on standards set by management, then just delivering software that works isn’t going to be in the developer’s best interest.

Throw in peer reviews and peer pressure becomes a good thing.

Before you upstanding, accountable developers start huffing and puffing, let me state that of course many developers take pride in the quality of their work without any outside influence. If you put your name on a module there is some consideration of getting your reputation tarnished by shoddy work.

But put that same developer under the intense pressure of a tight deadline and in short order they just aren’t thinking that far down the road.

From management’s perspective, they too will operate based on what is important in the company culture, what will advance their career and what will put more cash in their pocket. If you’re lucky enough to work for high quality company, then management will also care about what makes the software shine over time.

The fact is that if developers are incented to deliver code on time with no regard for overall quality of standards, then that is exactly what will happen. Code is delivered on time, passes quality assurance testing and seems to work just fine in production. Everything is hunky dory.

Or is it?

As soon as that software needs to change or the software it is integrated with changes, all of a sudden problems arise. The original developer may not even be with the company any more, thus a new developer has to deal with spaghetti code.

Next Page: the dreaded "standards" word

This can be a nightmare if the change is being made after a production crash and the pressure is turned up to move fast.

So what to do? You must implement standards for code design, coding structure, inline documentation and unit testing.

Take the time to investigate automation options available. These types of automated testing and code evaluation products provide management and developers unbiased visibility into their code and can greatly simplify developer testing.

Sure, it may take longer at the beginning as everyone gets used to the new standards and procedures for writing and testing code, so patience is important for the culture to take hold. Yet over time, the productivity of everyone involved in the life cycle will greatly improve.

Try to find automation software that provides simple grades for management to understand, but also enough detailed feedback to make it easy to redesign and create better code and tests. For the grades and feedback to be effective and efficient, it’s also important to have an easy interface to build evaluation rules that meet your standards.

Can’t find automation software that meets your needs? Then do it the old fashioned way. Create sample code snippets and unit test templates for your developers to use. Create training so that new developers can easily follow these standards. And create methods to grade each deliverable.

Most important - enforce it! Use peer reviews and include the results in annual reviews. You may be considered the bad guy (or gal) for a while, but over time the culture will change and the code will get better. Overall productivity will improve.

I think there is nothing like some good banter between developers in peer reviews to not only identify improvements and bugs, but also to promote creativity. As an added bonus, peer reviews are a very natural team building exercise.

Be prepared for the argument that you are in actuality stifling their creativity. I think it’s the opposite.

Putting in a framework that everyone must adhere to will result in a better balance of productivity AND creativity. This combination is more important than one or the other.

As for Trey, he reluctantly relented and eventually became a believer in the peer reviews. It seems that the more mature programmers see the value in following standards and those less experienced come to appreciate it over time as they themselves inherent crappy code.

ALSO SEE: Are These Developer and IT Salary Figures Accurate?

AND: Finding The Coding Zone: Your Perfect Trifecta?

Eric Spiegel is CEO and co-founder of XTS, which provides software for planning, managing and auditing Citrix and other virtualization platforms.

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved