Recently, I’d been working on a file-importing feature for a client. They had described to me how they expected to receive their data, clean it, and import it—just like they did with an existing tool.
I implemented the feature and got it working on my own computer, so I moved the new code to the test server. I tested it out on the test server with a sample input file I’d made following the process they described.
I documented the steps for testing the file import, with commands and possible outputs. With these steps documented and the feature working on the test server, I invited our client team to test it out. I did not send them my test files, since in the end, they would need to produce the input files themselves, and I wanted them to test the whole process.
A Long-Distance Problem
My clients walked through the test instructions, and the data failed to import.
More specifically, the program I had written was trying to process null characters that—according to our process and what we knew—should not have been in the input files. My clients sent me the files that failed, and I could reproduce the problem with those files. I downloaded software, so that I could replicate their process to create an input file, and I gave them a simpler set of instructions. I was confident it would work, because I’d replicated their process based on what I knew, and I’d tested on my own machine and on the test server.
Nope. They still had the same error. What could it be?
A Solution through Screen Sharing
File encodings are a big deal in file importing. I learned more about file encodings. Could it be that our machines differed in “endianness?” Should I dig farther down into what bytes were in the input files?
I could have gone that route—a techie, computer-geek route of looking for problems and their solutions closer and closer to the hardware. Instead, I decided to screen share with my clients while they walked me through an existing import process that worked for them. I replicated this process, and then screen-shared when we tested the new process.
Ta-dah! It worked. Screen sharing took out a minor glitch in our communication about the steps they were taking to prepare their input files. Thirty minutes after our screen sharing session, everything was working.
Why didn’t I screen-share before? Well, our conversations before had been reasonable, and we all thought we understood one another. Screen sharing can be a little stressful on a remote team where people have never met. Screen sharing while typing in the command line and looking in databases has another level of stress where people in technical roles (including me!) are nervous about messing up and looking stupid.
Luckily my client and I got over that, worked together, and laughed (and cheered) when we got it working. We were on the same team.
A Human Take-away
Without screen sharing with the human who was using the code I was writing, I might have wasted hours of our client’s time and created unmeasurable frustration going after technical problems that didn’t exist.
Atomic Object prides itself on having developers work closely with our clients. In fact, all developers have the title “Software Developer and Consultant.”
This learning experience put the “consultant” in my job title.