This doesn't happen anywhere near as often when

• You have a repository that records checkouts and checkins
• You have a sufficient set of regression tests that run periodically (at least once daily) against the repository
• You move from individual ownership of code to group ownership

Unless you have a repository, you're eventually toast. And any repository worth its salt will let you quickly tell who changed what, when, and will let you run a diff between different versions of a file (e.g., here's what so-and-so changed while I was gone).

If you don't have a sufficient set of regression tests that run automatically, breakage gets overlooked or hidden, and it's easier to pin the problem on someone else. To maximize peer pressure, the regression test suite can produce a web page listing modules that fail, showing also any recent checkins that might impact the failing module (and who made the checkin).

When the group owns the code, there's less opportunity for problems to be framed in terms of a dispute between two developers. Instead, it becomes an issue between the team and the miscreant developer.

This is where unit tests and source-control systems come in really handy.

The source-control system (let's say RCS, because it's ubiquitous) is nice because you can immediately tell what's changed (even if they didn't check in their changes, you can diff the working code against the last revision), and by whom.

The unit tests are handy because you can immediately tell what's broken, and where. If you require unit test summaries to be included in each commit log, you win even more....

Unfortunately, both of these things are the sort of tools that get brushed off -- "oh, we don't need RCS, we'll just remember to tell people when we change their code" -- until their absence bites you in the ass.

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!

As the others have stated, a source control system takes care of this.

If you don't have access to one then at least you can "discuss" the fact they didn't add something to the comments section of your script.

My co-workers would not dare touch my code without discussing it! ;-)

In a professional sense, look at the value achieved here: 'Buddy' saved thirty minutes by not copying the code and commenting his changes, and you lost six hours to find out what happened and additional time to 'unfix your mistakes.' Assuming the whole process took you 8 hours and both you and Buddy make $20/hour, I figure it like this:

(0.5 * $20) - (8 * $20) = $10 - $80 = -$70.

As a project leader, I have never been willing to spend money to compromise the team (loss of morale, trust, etc). Of course, I am a bang-for-the-buck kind of guy.

Short Answer: Buddy screwed up by saving time and the project lead screwed up by ignoring it. I would be just as angry. Take precaution in the future to protect your work and move on. If it happens again, Simon Travaglia has created a creative reference to inspire appropriate response. If nothing else, it makes for good reading!

Our game writing good sofware. More often than not our peers help us and we help them. Those few who don't - well, they are missing the best part.

Rudif

Example: a few years ago for a project we doing, I had to modify about 150 tables in a database, create or modify 3 triggers on each of those tables, and create a stored procedure and an index for each of those tables. That meant about 450 modified or new files, and 900 new or modified database objects. More than 50,000 lines of SQL, all generated by a Perl script.

It was going to be the biggest bulk submit we had done so far, and there was no way of doing this cleanly during the week when dozens of other developers would be submitting stuff.

So, I had claimed exclusive use of the development area during a Saturday. Late in the evening the submission process failed. Because of bugs in the submission software (a Perl/Tk program, maintained by a totally incompetent programmer). I could do two things, either wait till Monday and let the programmer in charge try to fix it. That would mean I had to delay the submission process till the next week - causing havoc on whatever day I was going to submit. Or attempt to fix the problem myself. I chose the latter. It turned out that I didn't completely fix the problem (because the author was a great believer in "cut-and-paste" and I hadn't found all the copies of the same piece of buggy code), but at least I could submit my stuff.

Did I leave a long note to the programmer what I had done and why? Hell no. I emailed his supervisor (which was formally my supervisor as well, but I usually ignored him and dealt directly with his boss) saying I had fixed the buggy software, cc-ing the programmer.

If you are working in a company, don't assume ownership of code. It isn't yours - it's the companies. Others will fix and break things. Only if you are available 24x365 you might have a chance of exclusively working on the code. It's nice, and most of the times useful, to email the person responsible if you did change things. But it's immature to expect noone else to touch your code, or to be notified. Be your own boss if you can't stand it.

Abigail

For the most part I agree with you. But, if a programmer has to be the one responsible for a piece of code, then in a manner of speaking, that programmer owns the code, or at least the responsibility. Responsibility is a pricey word in a company, seeing as so few are actually willing to accept it. Either way, whoever is originally responsible for the code should know whenever someone else lays hands on it. Either by written message or through some kind of source control setup.

A coder who changes someone elses code does not have to document every change, but the previous author should at least be notified that there are changes. That takes all of what, 3 minutes via email...."Hey I changed some stuff in your program, and consiquently broke it."

I would think there is also a failing on the part of the supervisor who doesn't notify the original programmer that things have changed. Flat out, the whole deal is a communications failure in this fellows work environment. Unless of course this fellow didn't read his mail first thing? But I doubt that ;)