Leave a comment

The ‘Ghost in the Machine’

by Jerry D. Cavin, Senior Software Engineer

Jerry_Cavin-3

Jerry Cavin is also an Adjunct Professor of Computer Science and Astronomy at Park University.

How many times have you coded an equation and the results produced are not what you expected? Then you rearrange the equation and get completely different results! If the computer is calculating correctly, why does it produce incorrect answers? Could it be the ‘Ghost in the Machine?’

Gilbert Ryle’s notion of the ‘Ghost in the Machine’ was introduced in his book, The Concept of Mind, a critique of Rene Descartes’ discussion of the relationship between the mind and the body (the mind-body dualism). The expression has been widely used in the context of a computer’s tendency to make unexplainable numerical errors. Are the errors the fault of the human, or is it the fault of the ‘Ghost in the Machine?’ To gain insight into these mathematical errors made by computers let us examine how the ‘mind’ of the computer views our concept of numbers.

INTEGER NUMBERS

The ‘mind’ of the computer perceives finite number sets. The size of the number set depends on the size of the space where the number is stored. If the number is stored in 8 bits, the number set starts with 0 and ends at 255. One of the bits can be reserved to represent the sign of the value (i.e. + or -). In this case, the numbers that exist are from -128 to 127. Numbers can also be stored in a larger space, but that does not change the fact the ‘mind’ of the computer still perceives finite number sets. So what happens when 1 is added to the maximum value in a finite integer set? It wraps around to the smallest negative value in the set. In our previous example for 8-bit values, when the computer adds 1 to 127 it would give the answer of -128. This overflow, or wrap around error, can occur if you are adding, subtracting, multiplying or dividing. Integer overflow errors are dangerous because they cannot be detected after it has happened. The ISO C99 standard states an integer overflow causes ‘Undefined Behavior.’ This allows compiler manufacturers, conforming to the standard, to implement anything from completely ignoring the overflow to causing the program to abort. Most compilers totally ignore the overflow, resulting in erroneous results being calculated. Depending upon how the integer variable is used, the overflow can cause a multitude of serious problems. If an overflow occurs with a loop index variable, it may cause an infinite loop. If an overflow occurs with a table index variable, the buffer overflow may cause data corruption. Another strange condition can arise with integers that we do not see in the human world. Under some circumstances an equation may give an answer of +0 or it may give an answer of -0. These two values of 0 are the same, but it may cause some confusion. This is a problem to many older compilers; some compilers detect this condition and simply change the answer to +0. Newer compilers use two’s complement mathematical operations and never encounter this issue.

What does your computer do?

Continue reading


1 Comment

The Importance of an Automation Plan: When to Start an Automation Project

by Nadine Parmelee, Senior Quality Assurance Engineer

Nadine ParmeleeAutomated testing is a great tool and can be a tremendous asset to a development project, but it can also be a great effort and a money waster when it isn’t properly planned. There are almost as many ways to set up an automation plan as there are tools for automating. How a test team decides to utilize automation will depend in part on the complexity of a project, the expected longevity of a project and an evaluation of how to get the most value from the automation investment. Some teams use automation to create test data; others to run manual tests that are data intensive; still others use it for regression testing purposes. Deciding how best to utilize automation is the first step to creating a better testing process. The automation effort should enhance your overall testing effort and free resources from the most repetitive testing tasks enabling the project to be tested more thoroughly. Here are some of the most basic yet key elements of a good automation plan:

  • Planning when to start automating
  • Deciding which tool to use
  • Choosing which manual tests to automate
  • Designing your automation framework
  • Dedicating resources to running and maintaining the automated tests

In this series, we’ll begin by discussing when to start creating your automated tests.  If you start your automation efforts too early, you risk negating the benefits of the automation effort because of the additional time you’ll spend updating the scripts or automation framework due to project changes. Timing is always a balancing act: the times when you’ll most want to start to utilize automated testing are likely the times when demands on your resources will be greatest. Here are some guidelines for knowing when to begin creating automated tests:

  • Manual tests are robust and well organized
    A strong, manual test script architecture will lend itself to creating a strong automation architecture. Ad hoc testing will lead to ad hoc automation tests, which may not be as useful as well planned tests.
  • Application GUI is fairly stable
    If you are starting with record/playback automation, the stability of the GUI (graphical user interface) becomes even more critical. If your development team is still designing the user interface (i.e., where different fields go, what they will be called, what types of controls will be used for each field) your automation tests are going to be playing catch up with the changes.
  • Application is structurally sound
    Every automated test failure requires some analysis to see if the application has a defect or if the test needs an update. The time required for these analyses can really add up especially when the overall framework of the application is not completely baked.

Later on in this series we will look at ways to determine which automation tool is most useful to your projects, how to determine which manual tests are the best candidates for automation, and ways to build a robust framework that will help you get even more out of your automated tests.


1 Comment

Should “Good Technical People” Manage Projects?

by Phillip Smith, Vice President Operations and Services

Phil Smith Bridge360I’ve seen many people in the IT industry think about shifting from a “software engineering” job over to project management.  When I come across these folks in discussions, I stay on topic with the person long enough to discover their real motivation for change.  I ask them to think about how they want to spend their workday, because it really is important to maintain alignment between the way people are wired and the type of work they are asked to perform.

So let’s talk about the general differences between the two “types” of people we typically see in technical roles vs. project management roles.

People who excel with technical work are a strong blend of “idea” and “action” in terms of the way they are wired.  They love submersing themselves with great technical ideas and they are motivated to make use of all of the available tools and tricks.  They often use their free time keeping up with new technology, simply because they have a passion about it and have an appetite to keep learning.  They may stay up late at night reading manuals, or publications, or tinkering with things on their home network.  I don’t want to discount the teamwork aspects of working with technology, because they are critical to success.  However, working with technology does require a person to be comfortable with working many of their hours independently and somewhat isolated, because they are typically assigned tasks that require research and original thought that is performed at the individual level.

In contrast, project management work is very “people” and “process” centric.  Most of a project managers’ time is spent building relationship and influencing people.  They spend time facilitating meetings, gathering information, and communicating status or resolving issues.  A project manager who is savvy enough to manage their schedule, cost, and risk through constant communication will be even more successful if they also love taking advantage of formal processes.  When I refer to formal process, I’m referring to defined work patterns, tools, templates, and mechanisms for reporting and tracking.  A project manager will go to sleep very quickly if you put him or her in front of a technical manual, but that same person will become energized if you strike up a conversation about earned value or resource leveling.

Again, my point comes back to the question of how a person likes to spend their day.  If they are passionate about technology they are likely to be miserable if their job requires them to navigate organizational politics and never gives them time to work through the riddles of writing efficient code.  To this I say, let them be architects and engineers—why ask them to be project managers?

I will concede that there are a few people around who are oriented strongly as a mix of people, process, idea, and action.  These people are sometimes confused by the distinctions I’ve presented here because they are just as happy to be accomplishing something on their own in isolation as they are accomplishing things in a group setting where a lot of people interaction is required.  These folks can leap from a PM role to a technology role quite comfortably.  You’ll often find them excelling in various parts of the software development cycle as product managers, business analysts, technical leaders, or as quality assurance specialists.  These roles require a mix of technical understanding and desire to work with people and process.  So next time one of your technical people talks to you about doing project management work, ask them:  “How do you like to spend your day?”