Dancing in the wilderness

This blog is closing.

2010-11-25T22:13:00.000-06:00

This blog is closing. I've created a new blog at www.dancingwilderness.com. I will carry on from there. Come visit me.

Software Quality Specialist

2010-11-25T11:59:00.000-06:00

What is a software quality specialist?

Someone who understands functional testing.
Someone who understands unit testing.
Someone who understands performance testing.
Someone who can code.
Someone who understands software development methods and strategies.
Someone who is familiar with software development technologies and frameworks.
Someone who understands continuous integration and build automation.
Someone who understands version control systems and strategies.
Someone who understands application architecture.
Someone who understands the infrastructure on which applications run.
Someone who understands the impact of architectural decisions on code quality.
Someone who understands how to manage a good software development team.

That's me. That's what I do. I am not a tester. I make sure software has better quality, gets to the customer a little quicker, runs a little faster, and that all this is repeatable. By repeatable, I mean the team gets up in the morning and looks forward to doing this all over again. That's my measure of success.

Software testing is changing. Some say software testing is becoming obsolete. In some sectors that may be true. But software quality will never be obsolete. And where lives are on the line, or you are trying to shoot a tiny computerized-chemistry-set-on-wheels off to another planet and hope that it will get there and talk back to you, well, then it's mission critical.

Software Testing and Forensics Engineering

2010-10-23T09:07:00.000-05:00

When we think about reliability in software development, we often focus on the robustness of the application itself. Is it designed properly, will it fail cleanly if a hardware failure occurs, and will it stand up under load? We create test teams to exercise the software while it's being developed to ensure it's ready when we release it to our customers. The test team is a critical part of the software development process, and it's often one of the most difficult parts of a software development project to manage. How do we know we have a healthy test team? How do we know that our test team will continue to function efficiently throughout the duration of the project? What do we do if our test team breaks down?

In solving problems, whether we are consciously aware of it or not, we use tools called heuristics. A heuristic is a fallible method of solving a problem. Heuristics are things like rules of thumb, road-maps or methodologies, and models that describe the behavior of a system. A good example of a heuristic would be forensics engineering. Forensics engineering is the science of understanding what causes structural failure, and it is commonly applied to vehicle or aircraft incidents. The reason we say a heuristic is a fallible method of solving a problem is because the method may or may not work every time it is applied, and from experience we know that not every accident or failure can be explained. The fallible nature of heuristics gives us the freedom to take a heuristic from one area of inquiry and apply it somewhere else with the goal of shedding more light on the system we are trying to understand.

So, how might we learn more about software test teams by applying the methods of forensic engineering? A vehicle or aircraft is a self-contained, complex system operating under specific environmental conditions. A test team can also be considered a self-contained system operating within the conditions of a software or hardware development project. A vehicle or aircraft is a moving body and is therefore governed by the laws of physics. A test team can also be considered a moving body that interacts with external entities like the system under test, business analysts, project managers, architects, and developers. A vehicle is designed to operate safely within the laws of physics, but when the right conditions occur a collision becomes inevitable. The same can be said of a test team, and using the methods of forensic engineering we can understand how a test team may behave when adverse conditions present themselves.

One of the first tasks of the forensic analyst is to review the conditions or context of the failure. In the case of a vehicle collision, how fast was the vehicle going at the time of the collision? How heavy was the vehicle at the time of the collision? The speed and weight of the vehicle can tell them how much momentum the vehicle had before the collision occurred. What were the road conditions? Could the tires create enough friction to stop the vehicle before the collision occurred? In other words, what were the physical laws governing the system when the collision occurred? One of the most basic laws that is applied in this instance is the law of conservation of linear momentum.

The law of conservation of linear momentum states that the total momentum of a closed system of objects (which has no interactions with external agents) is constant. Here is the law expressed as a mathematical formula:

m1u1 + m2u2 = m1v1 + m2v2

Momentum is a product of mass (m1) and velocity (u1). The law states that the momentum of the first object (m1u1) plus the momentum of the second object (m2u2) before a collision must equal the combined masses and velocities of the two objects after the collision. Velocity is expressed as a vector quantity because it has direction and magnitude. Think of velocity as an arrow; the point of the arrow indicates direction, and the length of the arrow indicates the quantity of speed.

How might this formula describe a test team? A test team has mass in the form of testers. A test team has velocity in the form of direction and speed in that they have a set of test scenarios which they are executing at a specific rate. We might also define the velocity of a test team by the rate at which they find bugs in the system. What's interesting is that these variables often change over the duration of the project, and we don't always understand why. If the law of conservation of linear momentum can be applied to test teams, and the momentum of a test team changes, then it must follow that the test team has experienced a collision.

Collisions come in two different forms: elastic and inelastic. An elastic collision is one where the total kinetic energy (energy of motion) of two bodies before a collision is equal to the total kinetic energy after the collision. Think of two billiard balls in space. A moving billiard ball collides with a stationary billiard ball and stops. The first billiard ball now has zero kinetic energy while the second billiard ball travels away with all of the kinetic energy of the first ball. An inelastic collision is where the kinetic energy of the two bodies is not conserved after a collision. Think of a golf ball hitting the green. The surface of the green deforms, absorbing a lot of the kinetic energy of the golf ball causing it to slow down or stop completely.

What kinds of collisions could a test team experience that might impact their momentum. External collisions could come in the form of bad results from the system under test. News that the team is testing the wrong business processes can be considered a collision. These two collisions share common characteristics. They both come from outside the test team and they both have a large quantity of their own momentum. After the collision occurs the test team may be in a very different state than before. They may lose all their momentum but still remain intact.

Let's look at the first case which could represent an inelastic collision. Bad results do not mean that the tests failed. Often we want tests to fail so we can find bugs and understand the conditions that cause failure. Bad results are results that destroy the confidence in the team. One of the worst things that can happen to a test team is to have people lose confidence in the results they are producing. This can happen when the test team has little control over the system under test. They run a set of tests one day and they run the same tests another day but return different results. If they can't explain the reason for the different results everyone begins to focus on the skills of the testers, the tools they are using, and their testing approach. In other words, the integrity of the test team comes under stress and it becomes doubtful whether the team will hold together when the next collision occurs. Team members may leave the project, the project manager may decide to remove a tester from the project, or he may stop testing altogether.

The second case represents more of an elastic collision. The team already has momentum, but the new business requirements cause the team to change direction. Changing direction is not necessarily a negative impact unless the team ends up going backwards. The team may have to start over or re-test their earlier results, but the team still remains intact and is capable of regaining their momentum. It's also possible that the new business requirements provide much needed focus for the test team and end up increasing their momentum.

Another area where crash forensics is applied is in the field of aircraft safety. The story of AF 447 is one of the most famous crash investigations in history. AF 447 was a passenger aircraft that initially disappeared without a trace while crossing the Atlantic. Eventually some debris was found but the location of the crash made it impossible to recover the black box recorder. The cause of the crash was never conclusively determined, but the air safety authorities ordered that all pitot tubes be replaced on similar aircraft. It is highly unlikely that the pitot tube caused the crash, but authorities had to produce some kind of response to the tragedy to restore confidence in the industry.

A pitot tube is a device on an aircraft that measures airspeed. If a pitot tube freezes over when an aircraft experiences bad weather the automated systems on the aircraft can malfunction. Airspeed is only one small part of the equation in our law of linear conservation. By focusing on the potential for a pitot tube failure the authorities used a small component of the system to explain the failure of the more complex system as a whole.

In testing, when a team experiences an in-elastic collision like one similar to AF 447, the management or test team is often tempted to 'fix the problem' by implementing radical changes that may not really address the problem. Imagine a testing project where the results are “good” for 2 months, and then the results become “bad” and stay that way for another two months while the team tries to troubleshoot the unexplained difference. The team has no success in finding the solution until one day when the system under test is rebooted. Unix systems don't often get rebooted, so it's not surprising that this “solution” was not attempted earlier. The performance problem disappears after the reboot, and the team experienced so much pain and expense troubleshooting the issue that management declares that all servers will undergo performance testing prior to being released to the development teams for application deployment. It is highly unlikely that the new routine performance testing will prevent any performance problems, but with testing, as in crash forensics, management often reacts to “bad” results in a way that is not necessarily good for the team.

Another factor at work in crash forensics is friction. Investigators often try to determine how much friction was at play in the systems. For vehicles, friction between the road and the tires is a critical factor, and for any mechanical system friction between moving parts can play a big part in system failure.

In testing, black boxes can act as a form of friction. Think of a black box in terms of a combination lock, like the ones we used on lockers at school. With a black box you know what goes into the system and what comes out, but you don't know what is going on inside the system. In our combination lock example, we know that numbers go in (or more precisely tumbler movement), and either “locked” or “unlocked” comes out.

The problem with back boxes is that since you don't know what's going on inside the system you often have to perform exhaustive testing for each scenario. For our test team this means that our momentum is going to slow down considerably. With our combination lock example, let's say we don't know how many numbers it takes to open the lock. That means we need to test all combinations of all numbers to prove our system only opens on one combination. If we know that the system opens with a three number combination only, then the problem becomes a bit smaller. The more information we have about what's going on inside the black box, the better the test team is able to direct their testing to get the required results. In other words, the 'blacker” the box, the longer the test.

So, applying the heuristic of crash forensics and the law of conservation of linear momentum to software testing helps us understand the dynamics of test teams as they move through their projects. We need to be aware of collisions that may affect our teams, and we need to focus on maintaining or regaining momentum when the collisions prove to be severe. We need to recognize when we have experience an in-elastic collision and make sure we spend some effort re-assembling the team before we can expect it to begin gaining momentum. Finally, we need to understand what causes test teams to fail and not blindly react to the event for the wrong reasons.

Tell me about it!

2010-08-25T14:15:00.000-05:00

I'm an introvert. In fact, if you are into the whole type watching thing, I'm an INTJ to be specific. An INTJ is your typical mad scientist, rummaging through junk drawers looking for stuff to fix or new ways to put things together. The last thing that comes to mind for me is to tell people about the things I am doing. I guess that's why my blog is so thin.

Another problem with being an INTJ is that you don't stick with something for very long. As soon as the problem is solved, the mystery revealed, it's off to search under the next rock I go. I'm like a crow. Shiny things catch my attention for awhile, then I move on. I'm not ADD or anything. It's just that as an Intuitive person (the N in INTJ) I learn what I need about a subject quite quickly, and they I either do something with it or say, "That's cool!" and start thinking about something else.

I've often thought about writing. I write a bit of poetry, and I think poetry suits my personality type quite well. I've done some work on short stories and screen plays, but I've never really taken them anywhere. I've turned my short attention span into a problem that my mad scientist brain can solve by asking the question, "How can I solve the problem of writing an interesting story?" That didn't quite work because solving the problem and actually writing the story are two different things.

One thing I've learned about myself is that I don't really like working in a vacuum. I like working in a team. Working by yourself all the time sucks. I do tons and tons of research. My house is filled with books. I've studied dozens of technologies in the software field, but when you come across something cool or crazy you need someone to share that with, someone to feed off and bounce ideas around with. That's the hard part. It's a catch 22. If I don't spend time socializing online or otherwise, I just end up back in the dungeon solving the mysteries of the universe again, all by myself. No fun there.

So, the point is I need to get out there and start talking, start yakkity yakking it up. I need to leave my digital mark on the universe. I need to spread some vibes, generate some karma, toss a pebble, touch a butterfly (actually, I prefer dragonflies, but this is a metaphor). I need to make some noise.

It's a start.

Happiness is a skill...

2009-06-24T17:17:00.001-05:00

I realized something today. I've been all wrong about happiness for a long time. I've been slowly stumbling toward the darkness, and whenever that happens I begin to search for a lifeline. I have often searched the wrong places. Then, today, as I was following breadcrumbs around the Internet, I came across a revelation.

Happiness is a skill, not a commodity.

I didn't dream that up on my own. I found it on an interesting little site called Raptitude. People often confuse gratification (getting what you want) with happiness. I know I have. That's the root of the problem.

So, how do you get better at a skill? You practice. How do you practice happiness? Good question. A very good question. A question worth living for. Now maybe I can stumble toward the light for awhile.

Elemental

2009-05-06T19:14:00.001-05:00

Elemental

bursting point
hidden sanctuary
heat in the dark
burning the bones to ash
stillness untouched untraced
ripples ripples and shivers
shivering ecstasy of alone
of light
there transformed
you dance of air
the dance of time
and distance, distance
unbound
dreaming of something
to hold
you dance the time the time

Hammering the Seeds

2009-05-06T19:13:00.001-05:00

Hammering the Seeds

(for Michael Olito)

frozen
a drift
on the prairie
no tracks in the snow
no bit of fence
to guide
a ghost
towering through the rows
dragging the plow behind
cutting deep swaths of stone
hammering the seeds home
hammering the feather once taken
roaring at the
roaring mausoleum
running with the herd
still running
watching
listening
trembling

Kicking Time

2009-05-06T19:12:00.000-05:00

Kicking Time

(for Lesly)

crunching the air
tapping snow
sticking
sticking the moment
awake
kicking time
then away from here away from now away
but now
cooling breath of fire
breath of ice
pushing tugging
against the cord
against the past
then dive into
the vanishing ice and snow
emerge to reach and
kick and
breathe and
flow of water
in furious stillness

3D IDE

2008-12-20T22:35:00.000-06:00

Imagine a 3-dimensional integrated development environment. When you launch the IDE, instead of being presented with a flat screen of files to edit, you connect to a server that hosts a 3D representation of the application. Components could be represented by different shapes, and the size of a shape might indicate the amount of code in the module. Colors could indicate the state of the code, whether it's green for a clean piece of code or red for an unfinished piece.

Imagine you can zoom and pan around the application to find the module you wish to work on and double click it to open the traditional file editor. The 3D window would update the view to indicate you are currently working on a module.

Now imagine a team of coders all connected to the same server, coding on the same application simultaneously. Imagine as each coder finishes a piece of code the 3D visual of the application updates to reflect the new feature. Imagine you could watch the application grow in real time. Imagine you could zoom into a module that is being coded and watch the developer work in a kind of virtual pair programming environment where you could chat with the coder as they type their lines and suggest ideas or changes to make.

Imagine how that would change software development.

Ghosts in the Machine

2008-04-27T09:32:00.000-05:00

We are the new ghosts in the machine. Our lives are now inside the virtual world on the other side of the screen. TV couldn't do it. Talk radio gave us the first glimpse of it. But, the internet has succeeded completely in creating a world that matters to us.

How many of us get up in the mornings on weekends, have breakfast and head straight to the computer? I do it, I confess. There's simply nothing here that needs my attention. Nothing here that gets my interest. And so, I come downstairs, turn on these screens, and look out there. Are we all doing it?

Work is no different. Our work days are spent staring into the screen too. Contact with our co-workers is done via email or instant messaging. We produce the results of our work in a virtual world, and nobody ever sees them.

Are we all just turning away from our lives and searching the murky world of the network for something meaningful? Is there anything meaningful out there? Or in there? I'm starting to have my doubts.

We live in an isolated world now. Never before have people been so disconnected from each other. Look at the rise of phone and online dating services. You wouldn't see these things advertised on TV if they weren't making money. People need connections to other humans, and if they are turning to these virtual versions of human contact, they can't be getting it in "real life".

What does this say about us as a species? What if lab rats stopped socializing with each other and started spending their days and nights in front of walls pushing buttons? Would we call that sane behavior? We would think there is something wrong with them. We'd euthanize and dissect them to see if we could find the source of the strange behavior.

The scary thing is, I don't think it will ever change. We're not going to turn off our radios. We're not going to turn off our TV's. We're not going to turn off our computers. As a species, we're not capable of that kind of discipline. We're hooked. We need them now to survive.

One of the big internet providers started limiting bandwidth usage by their customers this month. They made a lot of people very unhappy. Just the idea that they might get less internet had them crying out foul. Less connection. Less world.

What a strange thing it is to be human now.

Lean Software Development Model for Web Applications

2008-01-19T10:15:00.000-06:00

Last year I created what I call the Lean Software Development Methodology. This is a software development process based on Lean Manufacturing techniques. I created a Value Stream Map to illustrate the process and published it on my company website.

I have since let my company wrap up since I am no longer carrying on the business, but I wanted to publish the diagram on my blog for posterity.

There's no such ting as time

2007-08-18T22:14:00.000-05:00

There's no such thing as time. We invented it. By that, I mean time does not exist without humans. Time is a tool our scientists invented to help them measure things that move. Most likely time was invented to help measure rocks flung from catapults in order to solve the problem of how to fling them further than the enemy. Time is nothing more than an imaginary hammer.

So, what does this mean? Why should we care? Well, it's really very liberating when you think about it. No 'beginning of time', no 'end of time', no 'running out of time', no needing 'more time'. Can you imagine a world where there are no clocks? None at all, not even the notion of a clock? Yes, the world still turns, and the seasons still come and go, but no tick tock tick tock all around you all the time. Can you imagine that world?

Try leaving your watch in the sock drawer for a week. See what it's like. It's hard to really avoid time because it's all around us. It's on our phones, in our cars, on our appliances; it's everywhere. But, there will be moments when you will look at our wrist and realize you don't know what time it is, and realize that it's okay. In that moment you will feel free. And when you hear people talking about freedom, or read about freedom in books, or see films about freedom, remember that feeling. That's what real freedom feels like.