Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 2 down vote favorite

I implemented some functionality, then a business analyst created a defect, saying that some message text is wrong. Then I reviewed the spec again and found that I'm right. I posted a spec excerpt and closed the defect. Then she reopened the defect again, saying that there was a mistake in the spec and that I shouldn't implement it mindlessly and should escalate this particular thing to her.

How should I respond?

share|improve this question
4  
Do you realize that you didn't say a single word about the message text itself? Is it grammatically correct? Is the content correct? Is it understandable? Would it make sense to the final user? At least where I come from, I would ask these questions before deciding who's wright and who's wrong. – nikie Mar 26 '11 at 17:25
4  
What's BA? Sorry, english is not my native language – user1827 Mar 26 '11 at 18:30
1  
@M28: Business Analyst, the people who write specifications and review the implementation to see if it's conform. – Matthieu M. Mar 26 '11 at 19:24
3  
I will tell the BA that "I think there's nothing wrong with that message text. And it's a mistake that you created, don't blame me for implementing it mindlessly." She's blaming you for something she did wrong!! If she can do this here, she can do it again in the future and it will absolutely affect your performance report. Everybody will think of you as the bad ass, not her. – Phelios Apr 7 '11 at 2:12
3  
With Tact and Diplomacy... – Newtopian Apr 7 '11 at 3:39
show 1 more comment

7 Answers

up vote 17 down vote accepted

Ideally, you'd answer her by agreeing that the change was simple and easy, you'd do it, she'd be happy and everyone would move on.

I'm guessing because she's recording it as a bug, rather than asking for the change, other side-effects occur. Maybe the quality of your code or your work is being measured by the number of bugs you create. If that's the case, I'd answer her by telling her this, so that she understands your real concern.

It may also be that she finds it easier to raise a bug than go through whatever change control you have. If that's the case, maybe you could ask around about making the change control process lighter-weight, so that you can still use quality metrics effectively.

Sending messages back and forth isn't solving the real problem, which is your process and your ability to collaborate within it.

share|improve this answer
6  
Whoever using the number of bugs as a metrics is doing it wrong... – Matthieu M. Mar 26 '11 at 19:25
1  
we have no formal procedure of measuring amount of bugs developers make but it was told by the boss that one of each of ours goal is to make as less bugs as possible. From the other hand I had a bad experience on my previous job where management tried to blame developers for any reason and I know with what it all ended up, so I'm trying now to aggressively defend myself despite that conditions on a new job is not so harsh as it was on previous one. And I think this particular case is an example of what I had, BA is right, coder is wrong, despite of facts. That's why I'm so nervous about it. – user1449 Mar 26 '11 at 20:21
4  
Sounds familiar. If you can make yourself enough safe space to do so, try fighting that process instead of the BA. You'll get more useful work done that way. If you can't, talk to her about your fears. She will have similar measurements and she'll understand. You'll both end up collaborating to game a stupid process, and that's OK by me. – Lunivore Mar 26 '11 at 23:42
up vote 14 down vote

You are both right, to a point.

You did escalate to her by closing the defect with reference to the spec. She has now realised the spec is wrong and needs changed. Tell her to re-open the defect once the spec is updated.

share|improve this answer
1  
no, to raise a new change once the specs are updated (which may require a defect assigned to the BA), and link that change to the closed defect. It's a defect in the specs, not the implementation of the specs (which is what the original defect seems to have been). – jwenting Mar 28 '11 at 8:08
up vote 4 down vote

There's probably more politics and CYA going on here or it is a minor problem that doesn't need to be solved through formal channels. Without knowing how this person operates, it's tough to make recommendations.

Did you know it was wrong when you originaly implemented it? This is something to consider for your future benefit. You don't want to question too many of the specs (unless there are very serious and chronic problems) because you'll just get a response of, "Just follow the spec like I wrote it."

Follow the procedures in place of what to do to change a spec. The BA probably doesn't want to go through the red-tape, but you don't want to be blamed for a bug. Depends on how your firm handles those things; placing bug blame may not be a big deal.

Just decide if this is a battle worth fighting or save it for another day.

share|improve this answer
up vote 3 down vote

I'm assuming BA means Bug Administrator (unlike M28 above I am a native speaker, but I've never seen the term except as shorthand for a college degree). In which case, I am one. In our case things are pretty informal, i.e. nobodies going to send a nasty note to the boss or HR saying X exceeded his bug quota and job action is requested. I think it is best to avoid an adversarial relationship between the BA and the developersirement. I take the attitude that we are all working towards the same goal, "providing the best possible service to our customers", and the BA and the developers are part of a team with this goal in mind.

In our case, we don't have formal requirements, but we do have a users manual, and maintaining consistency between the UM and the code is important. It is good to log a found bug, -even its already been fixed, as a customer who runs into the same bug because he's using an older version of the code (pre-bugfix) can see that a similar bug was found and fixed and that he should obtain a more recent code copy. So bug logging, is not to be considered to be a demerit system for developers. Also we recognize that some developers work with Beta customers, who to some extent are also feature testers, and bugs reprts/fixes are a normal part of this process.

We call feature requests, enhancement requests. We don't always implement them. Sometimes a request -or even a bugfix, runs into too much technical debt, and would require too much refactoring to be done in the desired timeframe -or at all. Communication with the customer as to the propects of their requests, and the reasons for the delay -or denial are important. Oftentimes we can suggest other ways for the customer to meet his needs, without changing the codes, i.e. use feature X in combination with feature Y like this, and you can accomplish the same result as wanna-have feature Z.

The important thing here is that respectful, and truthful communication among all parties is crucial. In our case that extends beyond the formal software company, and into the domain of our customers.

share|improve this answer
2  
Bug Administrator? I assumed it was Business Analyst. – qes Mar 26 '11 at 20:39
Yup, sounds like Business Analyst. But +1 for "The important thing here is that respectful and truthful communication among all parties is crucial". – testerab Apr 16 '11 at 11:31
up vote 2 down vote

Sounds like there might be a bug in the spec itself if is incorrect, therefore it should be documented somewhere at the high level that there is an error in the original spec. This could be done either by attaching an additional document to the spec noting the change, or by updating the spec as a whole to ensure that the change is in place. However, such a change might require that the spec go through some form of a review board.

As such, I would create a new ticket to be assigned to the BA identifying the error in the spec and send it her way and update the original ticket with a link to the new ticket noting the error in the spec and then have a discussion with her to make sure the error in the spec doesn't affect anything beyond that one limited area of functionality.

share|improve this answer
+1 for a professional and constructive approach - having a discussion with the BA to make sure there are no other potential impacts sounds like a mature and professional way to handle this. – testerab Apr 16 '11 at 11:39
up vote 1 down vote

Respond by saying that this is a new requirement. A requirement defect is resolved by creating a new requirement, not by logging a defect to a software implementation of an existing requirement.

Logging defects is for defects in implementing a requirement, not on the requirement itself. What she's trying to do is drop the ball on you by creating a record of software defect (as opposed to tracking the defect in the requirement via a new requirement.)

With that said, understand the role your organization procedures play (will play) in the outcome. If there is no clear, written down procedure, it is a he-says/she-says game. If the procedure OKs the opening of a software defect as a way to fix a requirement, then you are screwed (I'd hate to work like that.) But if the procedure says to open a new requirement to correct a defect in the requirement, just point her to the procedure.

Regardless, good business analysis mandate to open a requirement to correct a defective one. Tell that to her.

Stick to your guns until she opens a new requirement (or someone from above forces you to bend over backwards.) If you win, you have a create a good procedural precedence. If not, it's hard to tell you what to do next.

share|improve this answer
Is framing this in terms of "winning" and "losing" really a good way to work together? This sounds like an unnecessarily hostile response - "she's trying to...drop the ball on you" assumes malice on the part of the BA, when there's nothing in the original question to suggest any more than misunderstanding about process. If you frame a disagreement as a battle, you may win on this one, but you'll lose overall as working relationships will become antagonistic and everybody will get to spend most of their time on CYA and paperwork. – testerab Apr 16 '11 at 11:29
You can only control what you do, not what others do. Unfortunately, work will entail conflict at one point or another (read "CYOA"). In my experience, the insistence by the analyst in modifying a requirement has tended to be either malicious or at least mis-representative. And remember that the win/lose clause I put is at the very end of my suggestions (paragraphs 1 and 2), and an analysis of context (paragraph 3 and 4). If after all that, you still get to a win/lose situation (specially after explaining the process to the analyst), you get there only by malice or incompetence. – luis.espinal Apr 16 '11 at 13:20
@testerag - con't. Moreover, I'm all for work synergy, but being unaware of the potential for conflict, that's just begging for pain. You want to be professional and team players at all times, but you must (for your own sanity) understand the behavioral anti-patterns that inevitably arise among silos (in particular between business analysts and developers, or developers and sysadmins and so forth.) The one suggested by the original poster is a textbook example of one. – luis.espinal Apr 16 '11 at 13:24
@luis.espinal. My point is that you can choose to reinforce those behavioural anti-patterns, or you can choose to work around them - I've always chosen the latter, having a history of working in very large very silo'd corporations, because forging good-out-of-silo relationships has usually been the only way to get things done without losing sanity. You also start out with the assumption that the BA is acting in bad faith "what she's trying to do" - it's possible to CYA and leave room for building a better relationship, but you can't do it if you assume malice from the start. – testerab Apr 16 '11 at 14:54
@testerab - I understand what you are saying, but I think you are reading too much into that last sentence of mine, ignoring the context around it in my answer. it's not about reinforcing or workout out those behavioral anti-patterns. And being on the defensive is not mutually exclusive of building good relations. Not being able to build them has more to do with hidden a) agendas, anti-social behaviors and malice than b) being defensive/CYA - there is no necessary/sufficient causation on b from a. I suggest you re-read my post, my entire post, not just the last sentence. – luis.espinal Apr 17 '11 at 16:44
show 1 more comment
up vote -1 down vote

Tell her that the more she forces you to think about spec the sooner you will replace her in her job.

Also, changes in specifications are named "Feature Requests", not "Bugs". If your tracker supports this, perhaps, the change in caption would satisfy both parties.

share|improve this answer
This is really bad advice: suggesting that the original questioner make threats about having a colleague they disagree with replaced is not a great way to build good working relationships. Especially given that responses to other questions suggest that part of his reaction is based on fears carried over from a previous bad environment, not current circumstances. – testerab Apr 16 '11 at 11:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.