Prologue
I bought a house this summer.
Nice place. An old farmhouse out in the country a ways but still close enough to GrammaTech that I can bicycle commute (which is important to me).
With the move came the chore of setting up various services. As a computing professional, a high speed internet connection was a consideration. If you haven’t ever lived in a rural setting, you might not know how challenging this can be. The process included over a month of checking availability from different carriers, contacting the companies who didn’t rule out a connection immediately, talking to friends and neighbors about what they were using, and a fair amount of mostly-pointless-but-somewhat-cathartic complaining on my Facebook page.
Several companies handled our interaction well, responding quickly to tell us that they don’t provide service to our address. Obviously, I would have preferred to hear that we could receive service, but as that wasn’t the case, a prompt and honest reply was the best they could do. Some companies claimed initially that they could provide service, but backed out when we actually requested the service. (This over-promising didn’t make me happy, but at least it was fixed quickly.) And some companies claimed to offer high speed internet services, but a look at their service details revealed they were actually dial-up services. (I didn’t even know dial-up was still an option anymore.)
One small local provider just never returned any contact attempt. We probably contacted them about 10 times, but they still haven’t responded. A large national provider spent weeks just stringing us along, providing vague answers about their service availability but never actually providing us with the service.
During the process, I began to think about what customer service really means. At some point, I saw an ad that claimed to provide SaaS development for businesses, but closer reading revealed that the company was just making standard desktop applications. I began to think about customer service as it applies to software engineering.
Software Has Customers
It is true that software development is an art – but no company is interested in purchasing your software-development-art for art’s sake. The software we make is developed because someone needs the capabilities it provides.
Here at GrammaTech, for example, we develop some software as part of a contract to create new tools and technologies for a specific customer, some software with the intent of improving existing commercial products or creating new products, and we even develop some tools that we don’t intend to sell but we use internally to improve the production of our other software, and then we’re the customers.
In none of these cases are we writing programs just for the sake of writing them, without any intended use. Our software has customers.
I would guess that the development efforts at every other software company also have intended customers.
The thing about customers is that they want something from your software. Just as you had a reason to develop the program, a customer has a reason to run the program (otherwise they wouldn’t be your customer).
Maybe the Customer Isn’t Always Right
Customers aren’t necessarily always clear on what they want. And sometimes, they want something that realistically can’t be done.
For example, consider my internet connection problems. What I wanted was a fast and reasonably reliable internet connection for my out-in-the-boonies home, and I was prepared for any particular out-of-the-box solution. Let’s use telephone wires, cable TV wires, a dedicated fiber connection, satellite signals, wireless access based on the cell phone system, wireless access based on local transmission towers, or anything else you can think of! The sky’s the limit.
This is analogous to a situation common in software development. The customer might have some desires, but they are often incomplete or fragmentary. The developers have to fill in some blanks based on the customer and a comparison with other potential solutions. A solution that would have required us to purchase a smart phone, for example, couple that phone to our computers, and use the phone as a wireless access point wasn’t a good fit to our needs for a variety of reasons. The fact that we didn’t explicitly express those needs at the start of our search doesn’t change whether or not they exist. I can call and ask a provider for service, or try to demand it – but if that provider has no connectivity within 10 miles of my house, the request is futile.
In software development, customers sometimes ask for the impossible. Sometimes we provide what may have been impossible. Other times we can’t.
Responding, Promising, and Delivering
So what should a software engineer learn from this process (other than not to move to the boonies if you want a high-speed internet service)?
We should all look at how we interact with our customers. They may not always be right, but they are still the ones who need the solution that we can provide, so we need them to understand what we can provide, and we need to understand what they want. This breaks down into a few lessons:
- Are we responsive to customer requests?
What are we doing to make sure our customers know what we’re working on and how it will improve their future use of the software? How do we let them know that we noticed their request? It is common in the software world to be secretive about development plans or responses to bug/feature requests. Although some circumspection is needed for intellectual property and competitive reasons, we need to be careful not to conceal too much. - Do we over-promise?
I was recently looking at the website for a software analysis package that claimed that the tool would examine every execution path through a subject program, in detail, for flaws. Unfortunately, the claim is only true for trivial programs, and making such a claim only leads to customers who are upset when the claim isn’t true in the context that they need. There’s a difference between a positive spin and a statement that could easily be proven to be false. - Do we deliver the right thing within a reasonable time frame?
Delivering the right thing requires an understanding of not just what the customer is saying, but what the customer really needs. This is a hard problem, and may take time to get right. A process that is too slow or unresponsive to discover and respond to the needs of the customer is a process doomed to fail.
Epilogue
As developers, most of us don’t directly interact with customers, and yet our primary function is to serve their needs. As such, we should start every new project by understanding who the customers are, what they want, figuring out how to explain what we’re doing to satisfy their needs, and understanding how well our software can deliver on our promises. Otherwise, your customers will feel like they are out in the boonies, trying to get internet service to their sad country home.
