Transparency is a Core Value in Work/Life

I am working on a current project where we are trying to create a site that gives visibility/transparency into our company and its performance whether good or bad.  This is being done in order to build relationship with those we do business with.  And it occurred to me how fundamental transparency really is in work and life. 

Lately, I have noticed a lot of examples of people and processes that are geared to pursuing transparency.  Regardless of what I think of President Obama's policies, I have to say that he has been fairly transparent with his decisions and agenda.  And every time some corruption (financial industry, legislative pork) or misbehavior is mentioned, his solution tends to be creating some framework (site or process) for exposing those ills through transparency.

It also occurred to me that a lot of project management processes aid us in exposing the truth about projects.  Risk management helps to expose potential issues that can ruin a project's timeline or budget.  Issues lists keep track of potential flaws in a given system.  And project post-mortems can help teams to learn from past mistakes and improve for future iterations. 

Even rating systems within eBay and Amazon or content updates from Facebook can help to bring a level of transparency that build trust.

So, why should transparency be so important? 

For one, transparency builds trustIf someone knows the truth about me, whether good or bad, they can begin to expect certain behaviors from me.  They can trust that I am who I say I am, and there is no fear that I will change or that there is something they do not know about me.

All relationships grow from a root of trust.  Without it, there is no basis for relationship.  So, if I want to grow quality relationships with my family, friends, and colleagues, I have to nurture trust, and therefore transparency.

It also creates a level of accountability.  If I am transparent about my life and work to myself and others, I am forced to face reality.  And even though reality is not always pretty, it can allow me to choose to pursue change.  Without it, I can safely live in denial and be complacent with the way things are.  And worse, if I keep things a secret, those failures may grow worse.  It was once said, "You are only as sick as your secrets."

The Bible concurs with these benefits saying that,

"If we say we have fellowship with him while we walk in darkness, we lie and do not practice the truth. 7 But if we walk in the light, as he is in the light, we have fellowship with one another, and the blood of Jesus his Son cleanses us from all sin."  (1 John 1:6-7)

You cannot have fellowship (relationship) with others and grow in your life without a level of transparency.

So, I have decided that transparency or being transparent needs to be a core value for me.  And this blog post is my first attempt at admitting that I need to work on it.  I need to be willing to be honest to others about my life and work regardless of the consequences and be humble enough to apologize when I have failed or hurt someone.  It's the only way to have the quality relationships and integrity I desire.

Web Service Naming Conventions

I was reviewing an interface for a WCF web service today, and I began wondering about web service naming conventions.

It is understood that a service should be a logical grouping of a set of functionality.  Therefore, if you have several pieces of functionality that center around a Project concept, then you should group them together under the name ProjectService. 

So, the convention for service names is:

  • Casing:      Pascal case
  • Format:     [concept noun] + 'Service' to construct the name.)
  • Examples:  ProjectService, TaskService, PersonService, etc.

When creating methods for a data service, though, should you restate the concept in the title?  In this case, you would use the following methods:  CreateProject(), UpdateProject(), GetProjectByID().  Isn't this already understood by the title of the web service?  So that you could say Create(), Update(), and GetByID() instead. 

I propose no.

The latter might make more sense in an object-oriented world where you are operating on the object itself.  However, a service is more like a manager class that operates on Project objects.  Also, theoretically speaking, each one of these functions can live on their own apart from any other functionality.  So, specifying the concept in the title of each method would make sense.  And finally, there might be functionality in this service for sub-objects such as Task that would not be substantial/independent enough to live on its own in a TaskService.

In that case, it would be important to understand which type of object your Create(), Update(), and GetByID() are operating on.

So, my recommendation for a data web service methods is:

  1. Casing:      Pascal case
  2. Format:     [operation] + [concept noun] + [optional extensions]
  3. Examples: CreateProject(), UpdateProject(), GetProjectByID()

What are your thoughts?