Does Your Code Work?

Blake Caraway — Thu, 02 Nov 2006 05:58:00 GMT

two basic questions

It seems silly and awfully fundamental, but ask any professional software developer this question:

Does your code work correctly?

When faced with answering this question, most developers will - and should - undoubtedly reply with a resounding "hell yes, my code works!". Now follow that up by asking another question:

Can you prove the claim that your code works correctly in the next 10 minutes?

The answer to this second question speaks volumes not only about a developer's skillset, but also the team he or she works with, specifically that team's ability to provide solid business value in a timely and efficient manner.

proving code works: the debugger is not the answer

Debugger. The name says it all. It exists so one can fire it up to determine what's going on inside an application line by line b/c the behavior is in question - i.e. there's a bug and you need to determine where it is and what conditions are causing it (duh). If the sole method of determining that your code does (or likely does not) work as expected is by firing up a fully-functional system and actually using the debugger to put the application through its paces by hand, then you are putting your business at risk. It's that simple. The more applications your company has in play, the bigger the risk. Developing - not to mention trying to sustain - business applications in this way is lunacy.

You must be able to prove that a particular system component is working before the final product is assembled. In my experience, this is not how the majority of software is developed throughout the industry. Unfortunately, I've seen (and continue to see) too many developers blindly bang out a new feature and then fire up the debugger to step through the code in order to see it in action for the first time, trying to make sure the new feature plays nicely within the application. Why do we accept this risky behavior that continually jeopardizes our business' ability to generate revenue by constantly turning loose half-baked, untested software applications full of goo into the production environment? Why do we then complain about the amount of time spent supporting said goo-filled application, as if we had nothing to do with bringing about this sad state of affairs?

Using the debugger as the only code verification method carries with it some of the following bad habits:

FEAR & UNCERTAINTY -- A developer is afraid of the code he just wrote, thus the constant need of stepping into the code and watching it run all the time in a fully functional system.
WASTED TIME -- Requiring a complete, fully functional, end-to-end application environment on your dev box so you can employ the 'code and debug' method of feature development can take a lot of time to set up just right. Making sure you have a fully-loaded database on your system, live web services running somewhere, a message queuing infrastructure configured and running, and/or maybe even a security/authorization infrastructure in place can take a lot of time to configure and keep in working order -- all so a developer can fire up the application and step through the code to see if it works or (more likely) not.
GREATER CHANCE OF DEVELOPER ERROR - The manual act of using the debugger to step through code verifying application behavior requires the developer to think about, remember, and reproduce all valid (and invalid) usages of a system component, making sure it can handle all the different imaginable scenarios. Without some sort of test automation, it's almost a certainty the developer will forget to run through one or more scenarios when stepping through the code manually.

I've actually seen developers test entire order systems by hand over a number of days thinking about all the various scenarios that *could* occur, generating actual XML files, waiting for services to pick up said orders, process them into the system, then query data 10 different ways from Sunday to determine SUCCESS or FAILURE. Wow. So now the part of the business that enables revenue generation relies completely on a single developer's memory and uncommon ability to work in this insane manner. Thusly, this developer is the ONLY person on the team that knows about this system b/c there's way too much tribal knowledge to share with others.

testing, testing...is this thing on?

A very obvious fix to this problem is, of course, automated testing. By supporting our code with unit (written before the code - i.e. Test Driven), integration, and user-acceptance tests (and automating them so they run regularly), we help ourselves out immensely by assuring we have a working codebase every step of the way. This feedback is priceless! That sound you hear when some poor, unsuspecting user discovers/proves your application doesn't work is the sound of potential revenue running to your closest competitor and then telling everyone about the terrible experience they had with your company. The earlier on in the development cycle you receive feedback from your code that it's satisfying all business requirements and behaving as expected, the better.

For some time now, we've been aware of the virtues of a software QA organization within a business. But for too long developers have viewed QA organizations as corporate 'bus boys'; there to clean up the mess made during a project's design and development cycle. I recently had a colleague tell me he needed someone else to test the code he's written over the past month (this is days before the code is going to be put into production - doh!). No doubt having multiple parties exercise code is valuable, but if you don't know your code works as expected and you are waiting for others to prove it, then it's time to rethink your approach. This irresponsible behavior on the part of individuals and entire software development teams alike must be extinguished.

Despite the rising popularity in test-driven design and the increased discussion of topics like automated testing and continuous integration, it's clear that most developers have not taken enough interest in these concepts so as to improve themselves by adding these skillsets to their development abilities.

on the road to improvement

Okay, so what are the concepts that go into developing good code supported by a battery of tests? In the blog posts to come, I'll discuss concepts and practices that will (hopefully) help transform developers from fearful, time wasting, error-prone hackers into confident, focused, efficient developers.

Rants

Does Your Code Work?