The Open Source movement has become a commercial market force, this didn't happen over night but has been gaining steam for more than a decade.  In most cases open source provides clients with a value proposition that would have been unimaginable in the not too recent past, access to source code, low to no cost acquisition of technology, and throngs of people developing software for you for FREE.  But with this upside is also a risk of shoddy code, continuous undocumented changes, and project direction that doesn't necessarily fit with your corporate vision.  I will be addressing the Open Source movement on my blog for quite some time but I want to address those "throngs of developers" with my comments today.

Test. Test. TEST.  With an open framework, such as Joomla or WordPress, anyone can write a module or component that is very useful and fills a myriad of particular niches.  One of our strengths at EO MediaWorks is the knowledge and ability to fix and modify these parts and pieces so that we can deliver well integrated and stable end products.  Invariably we spend a bunch of time chasing bugs in other people's code.

I'll talk about a specific example that happened just the other day that illustrates what I see as a lack of classical testing methodology.  I Installed a module to display thumbnail images where you could set the number of thumbnails you could display per row, essentially the number of columns per row.  It worked great to start when I had many thumbnails to view, but it completely broke down when I displayed a category that had fewer thumbnails then the specified display columns.  When I tore into the code wondering what I screwed up in the setup, I found the culprit was a very typical mistake that was clearly untested.

Perhaps I’m lucky that my training in computer science was at a time where we thought about the impact of every line of code we wrote.  This stemmed from writing commercial software that had to run on 8 bit processors with 64K of memory and limited if any hard drive space.  Today’s software while vastly more capable has also lost any semblance of interest in efficiency regarding size and in some case performance.  When you load a software package today that spans six of seven DVDs you have to wonder if there is enough functionality there to justify its enormous size; generally the answer to poorly performing programs is to get a faster processor, better graphics card, more memory, and bigger hard drives.  This kind of thinking is part and parcel of the way you see programs being written, they are written for the best case scenario and often aren’t tested against the minimums and maximums that are likely to occur.

Don’t get me wrong we all are going to find bugs that make it into production no matter how carefully a program is constructed.  What I’m advocating is a more structured methodology to testing that doesn’t rely on feedback from customers using released software.  Not everything is worthy of an elaborate alpha, beta, and production structure, but I feel strongly that a little more thought being put into testing would result in much more stable code.  “It works for me” is the battle cry of these code warriors in the open source wilderness, but others are using this code and they aren't all capable of tracking down bugs to make things work properly.

If I’m writing a control structure built to display thumbnails, where a user can define a number of columns, it is incumbent upon me to test a number of cases.
There are a number of ways to handle, perhaps display an error message that indicates to the user that the number of columns is set to an invalid value, optionally don’t allow invalid values to be set, or use a predefined value (default value) when invalid values are entered.  Default values can be confusing to users sometimes but that is for another discussion.
Test for this case and make sure you’re cleaning up your loops properly.

Make sure it makes pretty pictures but use a known case, for instance load six thumbnails and set for 4 columns and make sure that all 6 are showing.  It’s another typical mistake to get your conditionals set wrong so that you are exit your structure one item early.

Depending on the case I prefer to display a message indicating that there are no thumbnails to display, but there are cases where you will want to display nothing at all.

Now I know all of this seems rudimentary, and it really should be, but you won’t believe how many times I run across this exact type of error.  I’ll write a little pseudo code as an example of typical structure.

This pseudo code example is meant to simply illustrate handling of all possible situations is really quite easy.  This is certainly not the only way to accomplish this task, most programming language’s syntax have various looping structures such as for, while-do, or do-while.  The key here is to think about the possible cases and do something about them, whether they are valid or invalid, never leave it to chance.  The more proactive you are about approaching solutions in this manner the better your results will be, and you will be rewarded with more solid code.

Don’t forget the last step though. Test. Test. TEST.  Once you’ve successfully tested all of the indentified conditions you can move on and feel confident that you won’t have to revisit a piece of code.  Perhpas it's symptomatic of the beleif that code should be written quickly, but honestly it only takes a few more minutes to formulate and test solutions and I would argue that in the end it takes less time than going back and trying to figure out why things are broken.

< Prev