Other devs change my code, break behaviour and I'm asked to fix "bugs"

PJH

You think people read those?

I do. I use svn blame quite a bit* to find out who did what, and what they thought they were trying to do when I find bugs.

More useful to me these days, of course since, I forced ssh access requiring keys resulting in people's names appearing in the log messages/user column in the blame. (Rather then when everyone was 'anonymous' and relied on people putting their own initials at the end of the actual commit message.)

* And I'm apparently the only one in our group who knows how to do this (even after they've watched over my shoulder when I've done it,) and quite a few other things in svn apparently. Probably because I'm the only one who bothered to learn what SVN can do, use the the CLI a lot, and few tools seem to make the more 'obscure' either easy to do, difficult to find or, can't do at all. e.g.

create a personal working area (svn mkdir svn+ssh://example.com/branches/pjh)
make a personal copy of a branch (svn cp svn+ssh://example.com/branches/4.2 svn+ssh://example.com/branches/pjh/4.2_ticket_5234)
after a while, pull recent changes from that branch into your copy (svn merge ^/branches/4.2 on local personal copy, any number of times)
merge personal copy back to branch (svn merge --reintegrate ^/branches/pjh/4.2_ticket_5234 on local copy of branch)
housekeeping (svn rm svn+ssh://example.com/branches/pjh/4.2_ticket_5234 -m "ticket_5234 merged back into 4.2")

This is beyond the wit of, or too hard for, the others in my dept.

Ascendant

@PJH
@PJH said:

(Rather then when everyone was 'anonymous' and relied on people putting their own initials at the end of the actual commit message.)

Oh god.

anotherusername

@Ascendant said:

They don't comment on their commit. Period.

Then you should be able to revert it with prejudice.

PJH

@Ascendant said:

Oh god.

Quite. At least I was able to introduce some sanity into the business that day. (Most of it was in place anyway - everyone (of relevance, and quite a few others) already had their keys in a central store (which has its own quotient - it's a Trac wiki page,) I simply needed to (re-)configure the SVN server to change the authentication method and sort out the authz file.

@Ascendant said:

They don't comment on their commit. Period.

Oh - and I sorted that out as well. A pre-commit hook that requires that the commit message start with something that looks like a ticket number. Akin to /^(LANDING|CENTRAL|EXTERNAL)-[0-9]*/. Not utterly foolproof, but it works. At least for our department's stuff; I've not had a request to expand/force it to other parts of that server.

Ascendant

@PJH

@PJH said:

Quite. At least I was able to introduce some sanity into the business that day. (Most of it was in place anyway - everyone (of relevance, and quite a few others) already had their keys in a central store (which has its own quotient - it's a Trac wiki page,) I simply needed to (re-)configure the SVN server to change the authentication method and sort out the authz file.

I still don't know every ins and outs but at my first job they exchanged source code in the zip format through a chat messenger. (yikes)
I was still an entry/junior but I just downloaded the easiest SVN I could fiddle with(Visual SVN) and gave everyone an account.

@PJH said:

Oh - and I sorted that out as well. A pre-commit hook that requires that the commit message start with something that looks like a ticket number. Akin to /^(LANDING|CENTRAL|EXTERNAL)-[0-9]*/. Not utterly foolproof, but it works. At least for our department's stuff; I've not had a request to expand/force it to other parts of that server.

Hey that sounds brilliant. The gotcha is, they don't have a ticketing system.(That's a bug tracking system, right?)

To be honest, I've never been lucky enough to see or use one.

Oh btw, what bug tracking system would you recommend that's dead easy to setup and use with all GUI goodies?
I might as well introduce this myself.

stillwater

@Ascendant said:

So no tickets for me or you.

That awkward moment when you find tickets , fix like 5002 of them, and then you hear this from the tester. Go out for a break come back and finding 8920192 new tickets waiting ..

boomzilla

@anotherusername said:

No, a competent developer is one that doesn't change code until he understands what it does.

So there is no such thing as a competent dev? Sometimes we think we understand it but don't. Sometimes we make other sorts of mistakes. Sometimes you don't have time to figure shit out and have to start trying stuff and do your best to get 'er done without messing up lots of other stuff.

anotherusername

Honest mistakes or not always having the time you need is a world's difference from rambo coding because you're smarter than whoever wrote it and you don't give a shit about what they thought.

You ought to at least make an honest effort to figure out what the code does.

boomzilla

@anotherusername said:

If someone fucks up your code, which you wrote and which was working, and their commit note doesn't indicate that there was a good reason for it, then you should feel perfectly justified in un-doing whatever they did first, and asking questions later.

Because you're not a competent dev so why bother figuring it out?

Vaire

@Ascendant said:

someone changed my code for some reason and now it's misbehaving.

Is this normal for a team of developers? Like something inevitable arising from team cooperation?

Depends on the company. I would say that isn't UN-normal for someone to break your stuff, what isn't normal (or acceptable) is for them to assign it back to you as a bug to fix. I'd pimp slap someone for doing that =_=

JazzyJosh

@Ascendant said:

They don't comment on their commit. Period.

JazzyJosh

@Ascendant said:

they don't have a bug tracing system to begin with.

Ascendant

@Vaire said:

I would say that isn't UN-normal for someone to break your stuff, what isn't normal (or acceptable) is for them to assign it back to you as a bug to fix.

Yeah I was puzzled too. To even just raise a question, I had to know if this was something normal, especially the "What's the problem guy" has his own reasons for assigning it back to me as a bug fix, namely, "We are a team so you pick it up", which is totally valid. I approve of crew mindset but I can't just fudge some code that someone else was working on and then "Oh hey your code has bugs now. Fix it".

@JazzyJosh
indeed

@stillwater

@stillwater said:

8920192 new tickets waiting

Is that a comically exaggerated number or the usual number of tickets you get?
Is that normal?

stillwater

@Ascendant said:

Is that a comically exaggerated number or the usual number of tickets you get?Is that normal?

It is usually anywhere from 10 to 50 every day. When you go home for the weekend and come back it is not uncommon to find 73 bugs assigned to you.

If the workflow goes something like A->B->C.....Z

If A is fucked then it is understandable the Tester cannot test B,C and so on.But instead of filing one bug which is A, there are 20 bugs that go A is not working, could not test B, B is not working could not test C and so on all the way till Z.

The Developer fixes A and the rest get automatically working but the Manager sees 781 bugs on the Bug Tracker initially, of which only maybe 10 are actual bugs, and flips the fack out.

NTW

@Ascendant said:

That would be awesome. That is, if this company had unit tests. Not single one of the companies I have worked ever had unit tests.

Isn't the Enterprise grand? Ask 95% of enterprise dev managers what a unit test is and you will get an answer made up on the spot. Heck, ask any 2 developers what a unit test is and you will likely get different answers.