22

I work in a medium sized company but with a very small IT force.

Last year (2011), I wrote an application that is very popular with a large group of end-users. We hit a deadline at the end of last year and some functionality (I will call funcA from now on) was not added into the application that was wanted at the very end. So, this application has been running in live/production since the end of 2011, I might add without issue.

Yesterday, a whole group of end-users started complaining that funcA that was never in the application is no longer working. Our priority at this company is that if an application is broken it must be fixed first prior to prioritized projects.

I have compared code and queries and there is no difference since 2011, which is proofA. I then was able to get one of the end-users to admit that it never worked proofB, but since then that end-user has went back and said that it was working previously... I believe the horde of end-users has assimilated her. I have also reviewed my notes for this project which has requirements and daily updates regarding the project which specifically states, "funcA not achieved due to time constraints", proofC.

I have spoken with many of them and I can see where they could be confused as they are very far from a programming background, but I also know they are intelligent enough to act in a group in order to bypass project prioritization orders in order to get functionality that they want to make their job easier.

The worst part is is that now group think is setting in and my boss and the head of IT is actually starting to believe them, even though there is no code or query changes. As far as reviewing the state of the logic it is very cut and dry to the point of if 1 = 1, funcA will not work.

So, this is the end of the description of my scenario, but I am trying not to get severally dinged on my performance metrics due to this which would essentially have me moved to fixing a production problem that doesn't exist that will probably take over 1 month.

Improve this question
13
  • 1
    We are not a forum in the traditional sense of the word, we are a Q&A site that looks for answerable questions. Rants, polling, and discussions are generally don't fit our format.
    – maple_shaft ♦
    Sep 28, 2012 at 23:03
  • 13
    @maple_shaft: I disagree. This is a serious question looking for a way to deal with a real problem that happens when dealing with, shall we say, less-than-clueful end users. We've all seen it and been frustrated by it, haven't we? So ideas about how to deal with such scenarios are a very good fit for this site's format.
    – Mason Wheeler
    Sep 28, 2012 at 23:09
  • 1
    Is it not possible that there could be an answer to this question? Who will watch the watchers?
    – User Smith
    Sep 28, 2012 at 23:36
  • 2
    To benefit others reading this, this case represents another lesson to those of us who believe that documentation is secondary and that singing requirements is not important.
    – NoChance
    Sep 29, 2012 at 4:04
  • 1
    "nothing has changed" famous last words.
    – JeffO
    Sep 29, 2012 at 4:32

5 Answers 5

Reset to default
18

Disputes about easily-observable facts are actually quite easy to resolve: just observe the facts. If I say "there's a tree with purple wood outside my house," anyone able to come to my house can verify the truth or falsehood of my statement for themselves.

If they're complaining that FuncA used to be in the product and used to work in an earlier version and now it's not working, and you don't think it was ever in the product, ask them to prove it. (Or, in more gentle words, say something like "we're having trouble reproducing the problem. Could you help us out here?")

Give them a copy of the earlier version if they don't still have one, and get them in a LiveMeeting, and have them show you how they used to use FuncA. If they can't do it, then (hopefully) they're realize that it wasn't in there afterall and get off your case about it, or at least try a different tactic to get it implemented. (And make sure to get someone from management or PM in on the LiveMeeting.)

Improve this answer
5
  • They have showed a screenshot of proof that I can explain but it is only a partial so the details of the scenario are what they say they are they are not truly defined via the screenshot. Basically, what it comes down to is that MGMT is not very aware of the logic and at this point it is the word of an entire dept against one lowly programmer. (Also the previous version is the same as the initial rollout that occurred in 2011)
    – User Smith
    Sep 28, 2012 at 23:34
  • 3
    @UserSmith: That's why I said to use a LiveMeeting. It's harder to mistake what's going on when you have to actually perform it with people watching.
    – Mason Wheeler
    Sep 28, 2012 at 23:51
  • 1
    This answer provides a much better definition of proof than "the end user says so" or "I read the code." Stop and remember the last 10 times that as a programmer you were completely flabbergasted you could be so wrong despite staring at 1 = 1 in the code (when it should have really been 1 == 1, e.g.). If you think of proof in terms of "reading code" as an error-prone human then frankly your performance metrics should take a hit. @MasonWheeler has proposed you a more accurate and more appealing epistemology, it would behoove you to follow it.
    – djechlin
    Sep 29, 2012 at 2:32
  • In negotiations theres a saying "If you have to defend yourself, you have already lost". Proofing facts is the ultimate form of defense - as a rule, best not to unless asked, even then, keep if brief - less is more.
    – mattnz
    Sep 29, 2012 at 5:24
  • 1
    Marked as answer probably the most concrete answer. Although I had already done live meetings prior to posting this question. Plus one'd a couple others that were partially good answers. Honestly at this point I don't care about my metrics, it is more the fact that the fundamental structure of our IT organization is in such a state of shambles that this is even occurring that worries me.
    – User Smith
    Sep 29, 2012 at 12:46
14

This is not an issue that can be dealt with on facts - if you try, you will loose credibility.

First, accept that the software is "broken" - as it it does not do what the users want it to do. Now, accept that the users have a right to have the software do what they want it to do - thats what the software is therefore. So what we have is defective software and an engineer refusing to fix it.....

As a result if the system you run to set priorities, these users cannot get their software fixed by going through the normal channels, so they are using side channels and escalating half truths higher up the food chain to try to out maneuver the system, in the mean time, making your KPI's look bad(your main concern should be the customers, not your KPI's) - Your KPI's are considered "collateral damage" if they like you, or a beneficial side effect if they don't. However, they do have some control over how much happens - best they like you.

So what is happening is the system is broken, and everyone is trying to manipulate things to get what they want. They want a feature, and you want to keep your spotless KPI's.

Unless you can fix the system or learn to play office politics real quick, game over: you lose.

Note : None of this discussion involves Dead lines, bug vs feature discussions, who is paying etc. These are Facts - and facts do not matter (well, they sort of do, but they can be manipulated in so many ways....) in office politics.

Improve this answer
5
  • 1
    How can you lose crediblity if you can PROVE it?
    – Thomas Eding
    Sep 29, 2012 at 1:02
  • 3
    @ThomasEding Credibility in the business world is more about how others perceive you than about facts. If you become a target then no amount of facts will protect you. How many rock-star developers have you met that were complete frauds? I have met more than I would ever like to admit.
    – maple_shaft ♦
    Sep 29, 2012 at 2:36
  • 2
    I would agree with a good part of this, it is definitely a form of office politics. When met with any situation I would think the first course of action would be to deal with the facts, so you kind of lost me there, but I would agree with customers come first kpis second to a point until you are of course fired. +1 for a different take on the situation. +1
    – User Smith
    Sep 29, 2012 at 12:58
  • 2
    Never complain, never explain. Arguing makes you look weak. Listening to polite requests is good. Saying you will discuss their request with your boss for priority is good. If you argue, then do what they screamed about, it reinforces their unpleasant behavior. If they escalate, your boss's position power enforces politeness. Your boss can diplomatically explain his choice for your time. It also shows they are not the boss of you. When you address the issue quietly with your boss, you may hear words like "don't worry, I got your back." Stay focused, make product, rants will stop.
    – DeveloperDon
    Sep 29, 2012 at 18:47
  • @thomas Ask any innocent accused if a particulay immoral crime....
    – mattnz
    Oct 1, 2012 at 7:38
10

Organizationally, I sense a problem.

There is a hierarchy that includes the head of IT and your boss. If your organization is traditional (it doesn't sound like it is Agile), you are a resource and they are resource managers. You have a full time job called software development. If end users are directly requesting features, setting your priorities, and trying to manage your time, your managers are redundant. They may be accountable to end users, but if they are doing their job, you are accountable to them and they need to shield you from going out of focused developer mode into defensive developer mode.

A few points to set the context of my answer:

  • Software developers are not time travelers, so the results need to be judged for what they are, not what they might have been.
  • If a feature was in a requirements specification, a schedule, and was prioritized above work that was completed, there may be a legitimate complaint. Otherwise, what is the justification to hold you accountable?
  • Your punishment, if merited, needs to come from your chain of command. Just as marketing and sales would not like it if product development scolded customers, most organizations have product managers to receive customer wrath (and praise) and convey it through channels.
  • Product managers can create extremely difficult relationships if they bask in the warmth of successful parts of projects, but only ever crack the whip when they face toward developers.
  • If you delivered functional product with a year worth of work, and it takes a month (or two) to add the desired feature, from what I have seen in our industry, your estimation was above average.
  • Solving the problem fairly and productively requires that people put the fingers of blame back in their pockets and make a go forward plan.

You will be able to do much better quality work with better motivation if you are appreciated instead of being the goat in a process that the head of IT should own. It is the fair way and the productive way. I hope you will be managed that way, and sometime in the future, I hope you will manage others that way.

Improve this answer
1
  • DevDon,wish this was in with answer #1 as I think that this is a big part of our issue....our IT structure for this scenario is extremely haphazard. +1
    – User Smith
    Sep 29, 2012 at 12:49
1

In case of reality failure like this, the best thing is to move forward. Instead of arguing about the past, talk about making it work and how easy or difficult that will be. It doesn't really matter if the issue is fixing it or implementing for the first time. If management wants A done before B make it so.

Improve this answer
1
  • Of course this is true, but when the end-user finds out they can manipulate the system in this manner, my company will be in a serious downward slant if this continues as resources will be used in this way versus being used for overall company strategic directives that will really drive the companies bottom line.
    – User Smith
    Sep 29, 2012 at 12:54
0

Are you the only dev to have worked on this project? Sounds like you answered to someone while making the project. Where is that person in all of this? Where is the documentation for the project saying what was delivered?

There should be a document paper trail. A training doc showing how to use the application. A functional spec outlining what was developed. If a feature wasn't included, there should be documentation on that too. Someone should have had to sign off saying they accept that.

It shouldn't be your word against theirs, it should be all in the documentation.

If you don't have this documentation...then I'm afraid you are going to have to bite this one. Consider it a life lesson. At the end of the day, your users are your customers, and as the saying goes: the customer is always right. Draw up how to add this feature and how long it will take. Have a meeting and say something along the lines of 'Our records show that this feature was never implemented, but we can get it life in x weeks. Should we go a head?'

And for the love of all that is holy....get the documentation you need to show it was approved.

Improve this answer
3
  • Yes, I was the only one that worked on this project. There is documentation with daily updates which I called proofC in my question.
    – User Smith
    Sep 29, 2012 at 12:52
  • @UserSmith ~ I took that to mean more of a daily status update. That's not really the documentation I was talking about. Did someone sign off on the final product? Is there training or any application documentation you gave the end user or the stake holder?
    – Tyanna
    Sep 29, 2012 at 17:58
  • Unfortunately no. There was training but very short period of training. There is application documentation but it does not cover the lack of this functionality being present. The daily updates are basically a journal tool we use to describe initial, daily, and final descriptions of what happened with a project.
    – User Smith
    Sep 29, 2012 at 18:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.