Consider The Customers

It often surprises me when my fellow software engineers seem to forget our customers when designing software.

There are at least three major customers for any piece of software and it pays to remember their needs with every software project.

The first group of customers are our bread-and-butter. They are the users of the software; the humans that will need to discover and rediscover how to make it work for them. It can be a lot of work to keep users happy but the developers’ reward is certainly there if you can create a product they can use effectively. Satisfying users gives you an opportunity to literally make their lives easier. When we focus on the users, we are literally adding value to their lives.

Our second, equally important customer is the person or entity that is actually paying for the software. If you are lucky they are the same as our users but often, we are not so lucky. Examples can include: the enterprise software decision makers, our bosses in the mega-corps, and/or those incredibly amazing users that are actually willing to pay for the tools they use.

Together, the first and second groups of customers are pretty darn important and it pays to keep them happy. Without those customers, there wouldn’t be any Twinkies in our desk-drawers or beer in our mini fridges home refrigerators. They keep us employed.

And yet! I am asserting that there’s a third customer and this group of customers is often neglected the most. It’s a case of the “Cobbler’s Children Have No Shoes“. Our third customer is the software engineer that will need to come back and evolve the software product and/or fix our mistakes.

This engineer is often a future version of ourselves that have completely forgotten the nuances of the code after having been away from it for six months or a year. Other times, it is a teammate that has been tasked with maintaining an existing design. I am a firm believer that “code is read much more often than it is written” and believe it is important to remember that someday, someone will be looking at every line of code I write.

I don’t know about you, but if I can help it, I would like to limit the amount of bad code I have to defend when I arrive at those Perly Gates.

Sure, it can be fun to develop clever solutions to a problem but if the maintainer of the software isn’t able to discover how to use or modify the software in a reasonable amount of time, then the solution is a failure.

There are a number of ways to help “the next guy” including detailed commenting and well-structured, well-thought-out software designs. The important thing is to actually remember these customers maintainers every time we write even a single line of code.

Problems inevitably arise when we put ourselves above our customers. When we develop products using short cuts or don’t consider all of our customers’ needs, we look unprofessional and our customers suffer.