Category: Quality Assurance

Posted on by — 2 Comments

Today’s Programming Advice – Code for the impossible

Always code for the impossible case! The impossible tends to happen surprisingly often. The programming language is irrelevant. Whether you code in C, C++, F#, ColdFusion, PHP, JavaScript, or whatever, conditional statements and case statements should always accommodate the unexpected value.

Right now I am dealing with some code that involves a list of 1 or more items. The actionable part of the code involves clicking on one of the items in the list therefore at least 1 item must exist. Having zero items is impossible because if there were no items then I could not click on the item to start the actionable part of the code. So why waste time coding of the zero items case? This is not the best example since this is a multi-user, client/server web application and the zero case can be created quite simply by having two users pull up the same list and then one user deletes an item before the other. But that answers the question of why waste time coding for the impossible? Because it does happen. My code frequently has conditional statements that end with a default case or a special case that simply outputs "This is impossible. Please contact the administrator." and includes some debugging information. In my career, doing this has saved me hours and hours of debugging time on more than a couple of occasions.

Posted on by — Leave a comment

The Joy of Software

I’ve written this PHP application. I work on a development server. Then I move code to a staging server for preliminary testing and client approvals. When the code is ready, it gets moved to a production server. In an ideal world, dev, staging, and production would all be configured identically. In the real world, you get different operating systems, different versions of the middleware application software (PHP, ColdFusion, .NET, etc.), different version of the databases, drivers don’t match, security patches are applied on one server but not another, and so forth.

So, this PHP application has a calendar piece for associating a date with a form collecting data. When adding a new thing, the form should have certain default values and the date should automagically show today’s date at 00:00 hours for the starting date and today’s date at 00:14 hours for the ending date. This works great on the development server. This works great on the staging server. But on staging, the date defaults to December 31, 2008 at 19:00 hours for the first date (the beginning date) and December 31, 2008 at 00:14 hours for the second date (the ending date).

It’s the little that make life so interesting and keep the padded rooms booked up.

Posted on by — Leave a comment

Bring Me A Rock

When talking about software development and software quality assurance processes, I love to talk about the "Bring me a rock!" scenario. I found these renderings of a rock rather amusing. Of course, there are no coffee grounds in the house so that could be a contributing factor in the humor.

I also enjoy talking about delivering a baby in one month by using nine women. And I love the ugly baby syndrome. But those are for later.

Posted on by — Leave a comment

NOOOO! I slept.

This week I have made great strides at reducing my sleep schedule down to a reasonable 3 to 5 hours. Last night I considered an all-nighter but I was head bobbing and unable to focus so I committed myself to a couple of hours of restorative sleep. A couple of hours turned into too many (5 or 6 maybe 6.5 or 7). I despise sleep.

Time to write some test plans. Yes! I’m actually getting to apply real honest to goodness quality assurance stuff to my work! By no means, does this come close to IEEE but its something.

Posted on by — Leave a comment

I like my work

I build very complex web application systems. I mean so complex that sometimes I forget that certain functions were built into the program; sometimes they surprise and even impress me. One of my habits is to code for the impossible. I often will slip in error messages for conditions that should never occur.

"Ever since the first computers [t]here have always been ghosts in the machine. Random segments of code… that have grouped together to form unexpected protocols. Unanticipated? There free radicals engender questions of free will… creativity… and even the nature of what we might call the soul." [Source] excerpted from I, Robot

Tonight I was testing an application I am trying to launch when I received "Something strange has occurred. Please log out and log back into the system then try your request again." Strange indeed! I usually make my impossible error messages a little more meaningful.

Posted on by — Leave a comment

What is legacy code anyway?

Legacy code is software that was written previously by yourself or another developer, left to rot probably undocumented, then after a time brought back to the table as a project to be improved upon.

Code ages. And quickly! Low budget projects tend to be created with little documentation and lots of hacks or workarounds. "This will do for now. We’ll fix it in the next version." Only the developer saying that does not document the need for a fix or revision. This is called firefighting or bandaiding. As time passes techniques or functions that were once hot and vogue become passé and deprecated and sometimes altogether unsupported. One of my recent projects left me scratching my head for a week because the php function session_register() is deprecated and excluded from version php 6.

These legacy apps are also known as evolutionary prototypes. Evolutionary prototypes build features and changes upon the existing functioning application. They have a limited life. After a number of revisions, the application starts to fail miserably. It is like adding more and more plumbing to the house. Eventually you forget what that one pipe does but it exists therefore it must be important. Unfortunately, most clients just see the number of dollars spent building up to the current revision of their application and have trouble justifying the expense of a total rewrite.

Legacy code can be extremely painful to troubleshoot and down right painful to modify since the modifications might mean having to work in the awful practices the previous developer employed rather than using good, professional coding techniques even when the previous developer was yourself. However, most applications will fall into the category of legacy code so a good developer should treat all projects, even the small and under budgeted, as ongoing large scale applications with appropriate documentation of assumptions, explanations of hacks and workarounds, suggestions for future updates, test documents, and so forth. Clients should plan on a total rewrite after 3-7 evolutions.

Posted on by — 5 Comments

Bring Me A Rock!

In the Quality Assurance world, we sometimes talk about rocks. Putting aside the middle managers, the product team, customer service, the project manager, the end user and so forth, a product ultimately falls to 2 people or groups: the client and the vendor. The client describes what they want; the vendor fulfills the client’s needs. The industry does not matter; could be software, could be construction, industrial supplies, whatever. And the problems begin with the first conversation. See, the client and the vendor speak the same language but in different dialects. The customer speaks and the vendor thinks they understand and drawing upon their experiences in their industry moves on to make the product for the client.

Here is how it works:

Client: "Bring me a rock!"
Vendor, eager to satisfy: Rushes out and finds the perfect rock. Cleans the dirt from the rock. Polishes it and returns it to the client.
Client: "Not that rock! Weren’t you listening? I said, ‘Bring me a rock!’"
Vendor, thinking he understands better: Goes out, spends twice as long, finds the perfect rock. Cleans it, polishes it, checks with some managers who agree it is the perfect rock. And returns to the client.
Client: "Not that rock! I want flatter rock. That rock is too round. Bring me a rock!"
Vendor, slightly dejected but still enthused: Goes out, kicks around some rocks. Notices all rocks are round here. Travels to another location. Finds a nice flat rock. Returns to client.
Pattern continues…
Eventually…
Client: "Now that’s a rock! Why didn’t you bring me that one in the first place? Could I have two for the price of one?"

The subtle differences in the dialect and the assumptions made on both the client’s part and the vendor’s part often result in a frustrated vendor and a dissatisfied client. Unfortunately client’s often get frustrated when the vendor asks too many questions about the rock in the beginning. The client doesn’t understand why the vendor is so dense. When the client buys into the need to clearly define a specification at the beginning of the project, time, money and aggrivation is saved!

Really, Bring Me A Rock applies to all walks of life. We do this to our children too. "Clean your room." "I’m done. Room’s clean." "That room is a mess!" See the problem?