63

I don't know if I should be very irritated or what. I single handedly built over 300 queries for a large database, and developed a naming convention so I could find them later. No one else in my office even knows how to build a query, but I came in yesterday to find that all of them had been renamed. I am now having a very hard time finding things, and I am trying to figure out what to do.

I spoke with the person responsible, and she just downplayed the whole thing. She said she renamed them so she can find them more easily. Unfortunately, I am the only one who knows how to build, edit, and maintain them, and the only reason she needed to find them was to test the queries. The new naming convention doesn't make sense at all, and I feel like we have taken a backwards step in the development process.

What I'm trying to figure out is:

1) Am I overreacting?

2) What is the best way to handle this? I hate to mention this to my boss, but after speaking with my co-worker yesterday, I can already tell she feels like she did nothing wrong.

Improve this question
18
  • 29
    Even though we work on teams, there is a concept of who owns what, and permission should be asked before changing code someone else has authored. Once I did it (I'm ashamed to say) and I was reprimanded. When it's happened to me, I've changed it back and asked them not to do that.
    – Mike Dunlavey
    Commented Jul 7, 2011 at 12:34
  • 30
    Duel at dawn!...
    – user1249
    Commented Jul 7, 2011 at 16:23
  • 46
    You have a backup/SVN right? Restore to just before her changes, and relax.
    – JYelton
    Commented Jul 7, 2011 at 16:53
  • 11
    if someone renamed my code I would snatch the life right out of them like Shang Tsung!
    – Glenn Ferrie
    Commented Jul 7, 2011 at 17:00
  • 25
    If she has any children, rename them.
    – Matt
    Commented Jul 9, 2011 at 3:14

15 Answers 15

Reset to default
80

  1. Not really - that's an incredibly disrespectful thing to do.

  2. You've talked to her and we haven't, but it seems like you would be within your rights to restore the previous naming conventions from a backup or revert them if they are in a source control. DO notify your boss and coworker if you do this, and provide your reason (You can't maintain your own work).

The last thing you want to is get into a back and forth over this though so handle it as the situation seems to warrent, but it should at least be documented in case it becomes part of a pattern of disrespect.

Improve this answer
6
  • 81
    As an aside, if her role in the project is actually "tester", she has absolutely no right to change source code. Period. But I'd like to add that, to prevent this kind of situation, you should composed a small (bullets!) document that states the naming convention, since, in the future your company may hire someone to work with you, or even coordinate you, and it'd be within his rights to change naming if there's no official convention.
    – Bruno Brant
    Commented Jul 7, 2011 at 16:44
  • 1
    I agree with this answer. If you do nothing, you set a precedent that may exacerbate future disagreements.
    – JYelton
    Commented Jul 7, 2011 at 16:55
  • 2
    Explain to her how you naming convention works
    – Germán Rodríguez
    Commented Jul 7, 2011 at 19:21
  • 13
    Make sure you take away her editing rights to the database whilst you're at it...
    – Ant
    Commented Jul 8, 2011 at 8:38
  • 1
    @Ant: If the OP's example is the whole story, I think that might be a bit harsh. If there is more to it (or they never should have ha edit rights in the first place) you may be right.
    – BCS
    Commented Jul 8, 2011 at 16:34
116

Why don't you simply handle it like adults: sit down, non-confrontationally, and come up with a list of pros and cons for a naming scheme , agree on one and make it official by writing a short document describing it. Elicit genuine interest in her input so she feels (and is) involved.

If it's mostly a matter of taste and if she's the kind of person who absolutely has to have things her way, then just be glad that you're the bigger person and let it go. Life's too short to have a pissing contest of naming schemes.

Is the problem the naming scheme or that you feel you don't get any respect? If so perhaps you can work on your working relation. If you feel it isn't worth it then why do you care about what she thinks anyways? :) Another option might be that she truly doesn't feel it's a big deal and if you explain nicely that you're having trouble finding stuff perhaps you can change it back.

Improve this answer
4
  • 2
    I was going to say change it back and ask her not to do that, but your answer is even better.
    – Mike Dunlavey
    Commented Jul 7, 2011 at 12:28
  • This is pretty spot on.
    – Wayne Molina
    Commented Jul 7, 2011 at 12:30
  • 20
    And then make her change it to the NEW agreed upon convention :)
    – user1249
    Commented Jul 7, 2011 at 13:21
  • 7
    @konrad, you're overlooking one crucial issue -- a tester has neither authority nor any sort of business doing any kind of editing like this in the first place. @anon is the programmer in charge, naming conventions are properly his or her decision to make, and they are not up for a committee vote, let alone unilateral changes by someone who will never have to debug the code afterward.
    – Shadur-don't-feed-the-AI
    Commented Jul 8, 2011 at 20:14
36
  1. Database design includes permissions (GRANT and REVOKE).
  2. Testing includes testing permissions.
  3. Relatively few people should have permission to rename database objects.
  4. Your co-worker isn't one of the few.
Improve this answer
4
  • This is a very good point. I was wondering why a tester would have even had the access to this in the first place.
    – Justin Ohms
    Commented Jul 7, 2011 at 18:28
  • Because it's Access. There is no GRANT and REVOKE in Access. There are no permissions at all.
    – Kibbee
    Commented Jul 7, 2011 at 18:43
  • 7
    Actually there are permissions in Access, but I've yet to meet someone who understands how they're supposed to be used (let alone implement them)
    – Mchl
    Commented Jul 7, 2011 at 19:13
  • 1
    Because no doubt, this same company probably doesn't even have source control systems, let alone a qualified DBA who has locked down Access. btw you should look it up its not very hard to do.
    – Anonymous Type
    Commented Jul 7, 2011 at 21:47
21

"The new naming convention doesn't make sense at all" sounds like one of these might be the case:

  1. She applied some company norm to them. These are often used to make sure code is at least consistent, and in the best of cases can help peripheral things like small custom scripts to find code easily. In this case, you need to understand the norm and why it "doesn't make sense" in your situation. If you still think it's better for all the developers to leave it as it was, explain to them why exactly your method is superior, and ask if you could change the norm (probably OK if they agree it's superior) or forgo it in your case (unlikely and messy in the long term).
  2. She invented her own standard on the spot and applied that. This is more likely if she's new, and she should explain her rationale. You might learn something, and/or she might learn something if you then explain your rationale.

An important point is that it's not your (singular) code, if anything it belongs to, and will be modified by, the whole group. No criticism about code should ever be centered around who wrote it.

Improve this answer
3
  • 2
    +1 good point. everyone else answering assumes the questioner to have a valid naming schema. What if he/she is really the companies "information hoarder". Perhaps its the tester who is actually making it easier for everyone else (and anyone new) in the company to find queries.
    – Anonymous Type
    Commented Jul 7, 2011 at 21:50
  • Good points. If the naming scheme is good, than both parties will be able to use it (once they get used to it) no matter who came up with it.
    – BCS
    Commented Jul 8, 2011 at 16:40
  • 3
    @bcs Even in that case, the proper way to do it would be to inform the programmer FIRST and ask him/her to change the naming convention themselves, rather than sneaking it in and waiting for him/her to come to work the next day and discover his/her entire structure mauled.
    – Shadur-don't-feed-the-AI
    Commented Jul 8, 2011 at 20:16
16

I spoke with the person responsible, and she just downplayed the whole thing.

Then I'll tell you, unbashedly:

Roll back the changes.

Wage this war. Your manager should back you and solidify your authority.

Improve this answer
5
  • Agreed. Check with her first that there isn't a good reason why the new names are better. If not just change it back.
    – Richard
    Commented Jul 7, 2011 at 17:56
  • 11
    When is "Wage this war" ever good advice?
    – Sverre Rabbelier
    Commented Jul 8, 2011 at 12:06
  • 3
    @Sverre Rabbelier: ...When a n00b tries to install suboptimal software practices. The OP tried to reason with her. Now it's time to fix the problem. Debating ad nauseum with a n00b about something so obvious is unproductive and wasted motion.
    – Jim G.
    Commented Jul 8, 2011 at 12:13
  • 4
    @Jim Maybe the OP is the newb?
    – Joe Phillips
    Commented Jul 8, 2011 at 14:41
  • 3
    If she is not your boss, change that shit back and don't look back. I'm not saying wage war, but sure don't just let somebody act like they own the place. Project managers are the ones who are supposed to be enforcing coding standards. It isn't about authority as much as it is about experience, order, and a productive working environment.
    – Jonathan Henson
    Commented Jul 8, 2011 at 21:21
10

1) No you're not over reacting. Someone changed your work without telling you and brushed it off when you asked them why. That is extremely disrespectful and rude imho.

2) Are you the official DBA, or at least the person who has been made keeper of the DB? If so, change back the names and write up a conventions document for how you do things. Also, write a 'Users Guide' style document so that if someone does have to go into the DB and find something they can.

I would send this out to the group, not pointing any fingers, with a helpful note that you'd be happy to sit down and walk people through some of the nuances of the structure.

If not, then come up with conventions as a team and follow them as a team.

On a side note, for someone who had to test something to change the names of 300+ queries seems pretty childish. How much time did she waste doing this, and only so that she could find stuff? Instead of just going and asking someone for some help, she wasted her time, your time, and the company's time. Not to mention the code probably broke when she did this, thus wasting another team member's time as well.

If I were you, I'd wait until you cool down a bit, try and talk to her again. If that doesn't work take it up with the boss. That sort of cowboy mentality will put the entire team in a bind eventually.

Improve this answer
8

Renaming at random in the database could easily cause a production environment to go down. If those procedures were being referenced somewhere in code it could have serious consequences. You can do roll backs, but if a tester like this really does not know what she is doing, its not that far of a step to see the tester make some changes to production. That could mean lost business, which is why you should try to implement seperate user roles for developers and testers. We do it with our testers and it works great. Testers often appreciate it, because they don't have to live in fear of screwing up live data.

Improve this answer
5

It doesn't seem to be touched upon elsewhere, but any source (e.g., a query) put in a public place should be under a version control system.

Then if an co-worker changes your naming scheme, you can revert back to your working scheme easily (and see their changes; and potentially revert back if necessary). You also tie changes to specific users, so you can see who messed things up.

Improve this answer
2

Don't look a gift horse in the mouth.

Firstly, collective code ownership - they should not be 'yours'.

Secondly, if they've renamed them then ask the reasoning around the new naming scheme. Either they're using the queries - in which case it's kind of their call; or it is a first step in them starting to give you some help in maintaining these.

If everyone thinks they are 'yours' you'll never get rid of them, and move on to something new.a

Improve this answer
2

I don't know if this has been asked but which naming convention is the official version? If your version is official, then I'll say address the issue from the perspective. So instead of saying "Person X rolled back all my changes" just say "Person X made changes that are contrary to the official naming conventions". If there is no official convention, then I suggest letting her know you don't appreciate the changes being made without consulting you first.

In either case, I think waging a "war" isn't the answer. Even if you win, you lose.

Improve this answer
1
  • This is the only correct answer. If there is a naming standard, then the names should conform to the standard, and anyone wanting them to have other names is wrong. If there is not a naming standard, there should be a naming standard - the team, or the tech lead or whoever - should write one. Coding conventions like this are dull, but they are an essential part of the social fabric that allows a team to operate.
    – Tom Anderson
    Commented Jul 10, 2011 at 9:37
1

That is appalling behaviour. It sounds like she has no regrets, so take it to your boss and make a case to have her access revoked until she can be convinced not to mess around.

If your boss isn't technical, explain it in terms they will understand. Imagine starting work in a post room, where post is sorted into pigeon holes ready for delivery. You decide unilaterally to sort the pigeon holes by floor then surname instead of the current system of department then floor. It might make your life easier in the short term, but you would be murdered by the other post room staff.

It is beyond rude. I would be furious.

Improve this answer
1

Other than setting permissions to stop random people changing them, you should also explain as it is her job to test functionality, you cannot give any guarantee of reliability if random people are making changes to code.

Improve this answer
1

Like everyone said, she should not have done this, if only out of respect for you since your are the creator maintainer of these queries.

Having said that, I don't see anyone mentioning the fact that if she did rename your queries in the first place, it was because she couldn't make sense of your naming convention.
So the issue could easily be solved by documenting your naming convention and ensuring that co-workers have access to the document and can find what they need.

You also must be careful and take into account how other people will find and use your queries: if your naming convention doesn't allow them to do their job efficiently, then you probably need to maintain a more thorough list of your queries, using maybe tags and agreed keywords so others can find what they are looking for.

Teh key here I think is that no-one works in isolation and the best way to avoid stepping of each-other's toes is to communicate and agree on common ground rules.

Improve this answer
0

I would respond in the same way - downplaying your decision to revert everything back. Just revert her changes and write really short email to your co-workers:

"Reverted change rXXXX for now, because didn't understand it's naming convention. Thanks for trying though. :)"

Improve this answer
0

Yes you are overreacting.

There something called version control that among other things it is used to not have to beat the $#!7 out of coworkers when they mess with your stuff. Just rollback to the previous version and lock the file therefore letting her handle the anger. That will open up the opportunity for you to explain that performing radical changes on code that has dependencies on someone else's stuff without a solid reason and without asking first is not just wrong, extremely impractical and practically a sin.

Off course this assumes that your naming convention is better than her's and that you can actually backup this decision with solid objective arguments, if that's not the case the most wise thing to do start changing your code as soon as you can to handle the changes and try come up with a better naming convention next time.

Do not take it to your boss, the mature way to solve it is directly with your coworker, you'll have to work with her after that so its stupid to damage the relation for a easily solvable quarrel.

Improve this answer