Posts from  January 2013


Let's talk objectives first, not implementation

A simple request

A few weeks ago, there was a request in our planning system: "On the customer edit form, change the button that links to payments to green if the customer has payments."

The first thing that came to mind was why? As far as I know the customer edit page is very rarely used, and it's not a hot bed of activity to get to other systems like payments. Naturally, I saw no value in the request.

The next day, I stumbled to put this nicely by talking about the cost and perhaps we could prioritize it for much later on. Honestly, I need to get better at just asking one word: "why?"

Anyways, my customer agreed to de-prioritize it, at which point I felt a mutual understanding so I asked why it was needed, my customer helped fill in the value. When deleting a customer, he wanted to know if they had any payments so he could consider the consequences.

A flood of ideas

At the instant I heard this, a flood of ideas came to mind.

  • Why not enforce rules to prohibit deleting a customer with data in other systems?
  • Perhaps we need an archival feature?
  • Perhaps we could summarize information about users from other systems into a report instead changing a button color?
  • Even easier yet, why not just audit deleted customers so if someone needs this data in the future, they can find it.
  • Why are we deleting customers?
    • Are we cleaning up old information from a system without rules to enforce constraints?
    • Are we merging customers that were accidently duplicated? Perhaps we need a merge feature if this is common?

Objectives and implementation

The specifics of my ideas aren't the point, the point is everyone on a team has knowledge that can be shared, I've often been impressed by ideas from other people. Also, at the very least, everyone should know what they are trying to accomplish, the objective. How, is the implementation and can only be discussed in the context of the objective.

Asking why

When making or receiving a request, if you feel the urge to ask why, chances are something is missing. Even when you don't have an inclination to ask it, it may still be a good idea to force yourself.

Why objectives matter

There is the possibility that one could ask why to the point we get into a philosophical debate about words, that's not what I am after. My end is to understand the objectives of the business, the value they will add and how to measure if they are met. This way I can help ensure the value is achieved, which is what will make a business successful.

If I don't know the objectives, nor the value and metrics, then an implementation you hand to me may or may not achieve that objective. Furthermore, I don't believe people intentionally hide things, so if I'm not given this information my first inclination is to doubt if anyone else has even considered it. It's easy to get lost in implementation; it's one of the exciting parts of our work!

The cost of failed implementations

Anyone in software development dreads when we have to scrap an idea for another: first A, then B, then C. In my past this has often been paired with a lack of an explanation of what objective we were trying to accomplish. Worse yet, when I have asked why, I have often found no one else has asked why. Not only is this frustrating, it drives up costs. This alone is reason enough to talk about objectives first and implementation after.