… I compile my thoughts about programming

Consultants are advisors, not decision makers.

Overview

I was having lunch with my friend & colleague last week and we had a disagreement about whose decision it is to make a change when you see something wrong in the client’s software.

Mechanic analogy

My colleague used an analogy about a mechanic; it was a good one, so I’ll use it here.

Let’s say you bring your car in for a $30 oil change, and your mechanic notices a problem with the timing belt. My colleague suggests, he doesn’t just ignore it, he tells you it’s an emergency must be changed immediately (the emphasis is my friends).

Well I agree the mechanic shouldn’t just ignore it, and I was relieved my friend didn’t suggest the mechanic should simply change the timing belt, driving the bill from $30 to $930, but I’m not sure if telling the car owner they must change the timing belt ‘now’ is appropriate either.

In my opinion the mechanic should tell the customer what he found, the risk in not fixing it, outline the options to fix it, and the cost & associated risk with each option[1]. Then make a recommendation.

It’s the customer’s decision, not the mechanics, and even if the customer makes a foolish decision, it’s his decision, not the mechanics.

Fortunately, all the mechanics I’ve dealt with seem to understand this.

As consultants we’re advisors, not the decision maker

In my opinion, our role as consultants / advisors includes the responsibility to inform the client of any problems or potential problems you’ve noticed, the risks in not fixing it, options to resolve the problem, along with the costs and risks associated with each.

Unethical behaviour

To me it seems unethical to go rogue, and just start making changes the client doesn’t know about, and didn’t approve.

It’s also unethical to purposely instil fear, uncertainty, and doubt when explaining the options to the client so they make the decision you want them to; regardless of your intentions.

The client owns your time

After all, the client does own the software, is responsible for its maintenance, and they do own your time to direct as necessary.

Every consulting and/or employment agreement is different, but if you’re charging by the hour, it probably says something like this; they bought your focused efforts to solve their problems for a specific duration.

And how they spend your time (their resource) is up to them (within reason[2]).

So deciding feature X is more important than feature Y, or bug X is more important than bug Y, is their call, not yours.

An extreme example

But what if it’s a big important issue? What if it’s a major security flaw in the banking software you work on. The flaw is dangerous. The flaw could potentially put users at risk. The flaw could even push the company into bankruptcy.

But your manager doesn’t want to invest the time to fix it and his manager stands behind him. You’ve exhausted all other paths of reason, to the point of being on the verge of getting fired.

You still don’t have the right to change it … not even on your own time, because the software is their asset, not yours.

Your decision

Now I’m not saying you have no say, you can refuse. Bottom line: if they refuse to make a change that you feel is necessary and/or potentially dangerous, you can give notice and quit.

Exceptions

Like everything, there are exceptions to this general rule. Here are 2:

The first is if you are working on one task, notice another problem, and can fix it without seriously adjusting your time budget on the original task. An example of this might be noticing and fixing a 1-off error in a loop. I once had the responsibility of making manual year end changes to customer databases, with an estimated time of 3 days for each. It took me 4 iterations working smart within the allotted time to write and test a utility which dropped that task to a 1 hour job[3]. The utility was separate, so I didn’t change the base product, and it cost my employer nothing. So it is possible to make an impact working like this.

The second exception is you have built up a lot of trust with the client, and are completely unsupervised, making whatever changes deemed necessary to accomplish the client’s goals. I’ve been in this situation a few times, and can honestly say, it’s a rare situation to be in. It’s reserved for the situation where the client trusts your character and your responsibilities are so mysterious that they cannot make a decision, so they leave it up to you.[4]

In Summary

So basically, in my opinion, as consultants it’s not within our rights to make the decision to change or coerce the client into allowing you to change something. It’s our obligation to inform them of the problem, outline their options along with the risks and cost of each, and make recommendations.

… that’s it.

[1] Yeah, there aren’t too many options to discuss for changing a timing belt, but we’re discussing software remember.

[2] There are limits of course, everybody will have their own personal & ethical limitation, and many (not enough though) will have professional limitations of what they’re willing to do. Professional limitations might include, I was hired as a programmer, not a janitor, or worse yet, and Access developer. ;-)h

[3] I could’ve dropped it to 5 minutes, but 1 hour is where the 80/20 principle told me to stop. Somebody did this after I left, and it took significantly longer.

Like this:

Related

I agree with the overall point of your post, but I think the mechanic analogy at the beginning is not that good.

Let’s assume that the mechanic is being honest and not just forcing an expensive operation on the car’s owner. If the mechanic sees a problem that would endanger the driver and/or other people on the road, they better be pushing for that problem to be fixed then and there.

Sure, there is software out there that has similar consequences of failure, but in a general case, a better analogy would be the mechanic topping up your windshield washer fluid for an extra $10 without asking.

About

My name is John MacIntyre.

I’ve been developing Line of Business applications on the Microsoft Platform for over 15 years, almost all of it full SDLC. I think I’m pretty good at incremental innovations, coming up with pragmatic solutions to difficult problems, and designing flexible, reusable components without any nasty leaky abstractions or intrusive code.