It’s Called “Service” For A Reason

June 14, 2012

Well, we’re all writing services now.  This is a service, that is a service.  We need a persistence service, a web service, service generating service, and services that service other services. Please stop. Put the word, “service” down and think about what you’re doing and saying. Everything you’re writing ain’t a service. “Service” ain’t the new term we’re using for “code”. You’re not always writing a “service”, sometimes you’re just writing a class. When you’re writing a service, it’s got a higher purpose and meaning that your average piece of software. It’s got to service something, or someone.

The key to the word “service” is that is provides something to someone else. If you’re the only consumer of your service, it ain’t a service, it’s probably just a transport protocol or a marshalling strategy. A “service” is just like a real life service you would get from restaurant or a clothing store. It’s something that you need, and if it’s good something that you’ll want to use again. Services should be friendly to the people who are using them, so that they want to keep using them. They should be designed with the consumer in mind, and provide a pleasant experience. If you service does the equivalent of spilling coffee on your lap or ignoring you while you have a handful of clothes and can’t find the dressing room, then it’s not a very good service.

The problem here is that the design of services is really a usability concern. The designer is a developer, and the consumer is a developer. It’s the first bit that’s a problem. Developers often could give a damn about usability, and are usually only myopically focused on the task directly in front of them. We figured out years ago that we shouldn’t let developers design user interfaces, but now we’re giving them free reign to design services for other people. If you want to design a good service, do the same thing you would if you were designing a good user interface: Figure out what the customer wants, give them what they need, and then watch how they use it to make sure you did your job well. Anything else is just you coding in a vacuum writing a service no one wants to use, or hates using.

Settings

I would like to point out that if we work together today, or have in the past, my opinions may or may not have been influenced by working with you. Most likely they have been, but I have to say that to avoid offending people. You're so vain. I bet you think this site is about you.