Have you ever tried to put together K-Mart furniture? You know what I mean, the kind of furniture that you put together with a hex wrench?
Well, whenever I try to do it, I almost always end up putting the first or second piece backwards.
Of course I don’t discover this problem until I go to set the furniture for use and discover that some unfinished wood is flashing right out in front.
There is no way to fix this problem except to take it all apart and start over again.
Software development isn’t a perfect analogy to this situation, but when we think we can build a whole feature without putting it through field testing, more often than not, we end up with unfinished wood showing and making the whole thing an eyesore.
It’s not a requirements problem
Many developers are still under the impression that if we can get all the right requirements up front we can solve this little problem.
I’m here to tell you today that is not the case.
If you had the perfect set of requirements upfront and you built them exactly as they were described, you would still have this problem. As soon as users got your feature or application in the field, they would discover problems with it and in time, ways to work around those problems.
I am sure you have heard it said that users don’t know what they want, but that is only half the story. Not only do users not know what they want, but what they want may not even solve the problem.
Have you ever had a problem where you knew exactly what you needed to fix it, only to go to the hardware store, buy the exact thing you were looking for and come home to find out it did not indeed solve the problem?
Sometimes the only way to know that something will or will not solve the problem is to try it out.
A real software field testing example
I’ve been working on an Android application that is not yet released, but is basically going to be a fitness application.
Without giving away too many details, the goal of the application is to alert you of certain situations.
When I originally designed this application's alerting system, I thought that the application should alert the user as soon as possible and stop alerting the user once the situation was corrected.
Seemed like a reasonable assumption to me at the time. Seemed like a great solution to the problem.
I fully understood the requirements of how to build this solution since I had designed the solution. I was the user and I knew what I wanted.
The only problem is: what I wanted didn’t work.
I built the software exactly as I imagined it and tried it out. I found that the constant alerting was not only annoying but provided no useful feedback at all.
I had run this idea by multiple people before I had built it and no one saw this problem.
The only way I could have discovered the problem was to actually get out there and field test the application. I had to rethink the whole alerting system. It is a good thing I field tested it when I only had the barest of implementations done, otherwise I might have had to tear the whole thing down and start over like incorrectly built K-Mart furniture.
Don’t try and ice an unbaked cake
Let me tell you from personal experience. If a cake isn’t fully baked and you try to ice it, you will just end up with a huge mess. (Also don’t accidentally cook your wife’s birthday cake in 3 pans that are stuck together, because you think it is one pan.)
If you try to add all the bells and whistles to software that has not been field tested yet, you are going to end up making your life harder when you have to change and rearrange everything, or even scrap it and begin again.
Some tips for making sure the “cake is baked”
- As soon as you can get the feature into the user’s hands, do it. Even if it’s not completely done. Show the user what you have, ask them to try it out so that you can understand if that will be what they want.
- Try to use the feature yourself. Don’t just click through what you have built and make sure the buttons work as you expect. Try to use the software to solve the actual problem or real situation it is intended to solve. In order to do this, you will need to understand exactly what the business case for the feature or application is.
- Break the feature up into small steps. Have check points at each step where the actual use case or workflow is tested.
- Paper test. Create some mock-up and run through the mock-up like you are actually using the software to solve a problem or do some work. This feels really silly, but you will be amazed at what you will learn by doing this basic and easy step.
Just remember, there is no substitute for real world field testing and that is okay. Don’t try and work around this fact, instead try to accommodate it. Build smaller incremental features that will allow you to rapidly change direction or start over without losing much work and before you get married to your work.