Rekna

I have a programming horror story i'd love to share

In grad school I am taking an OS course where we are writing our own OS (called yalnix for those of you that have done it before). Basically we are implementing a simplified OS on an emulated machine.

So i'm working in my group and I was going through and adding more features last night. I need to add some more process queues for devices that we are adding support for. In doing so the program stops working so I look into the code to see what was going on. Basically one of my partners decided every time we make a scheaduling decision he would read every queue there is and if they are all empty he would then call the sys_call exit which is a function that kills a process for various reasons (why he would be calling that beats me). So in the syscall exit it then checks to see if a process invoked it or a the other function if it is the other function it halts the machine.

Anyway this solution while ultimatly correct was unessarly complicated and inneffiecent. So I added a counter every time we kill a process and if the number of processes we kill is ever equal to the ammount we have created I halt the OS (as per the assignment instructions). I then proceed to remove his code.

Later he finds out I did this and throws a huge fit because his code was correct. Even though adding more devices required a lot more work because of it and it was effecient. I tried to explain to him his solution wasn't ellegent. It used functions to perform jobs that weren't within the context of that function, required many lines of code, and scaled poorly. I basically replaced it with 3 lines of code that was a simple killed++ and an if.

Here is my question for you, if you were working on a project and someone else found much better solution than you used to implement some function would you be pissed if they replaced it?

This isn't the only time something like this has happend either. Early on before our kernel ran he wrote a vital function that was holding up the whole kernel. It didn't work and he was debugging it, at the same time I was debugging it trying to figure it out also. Then I noticed in the FAQ it talked about this problem, i did what the FAQ said and it then worked. He through a huge fit because I debugged his code.

Should programmers working in teams really be so proud of there work that they let it inhibit the entire development process? Or was I out of line in both of these cases? What do you guys think?

I'd think a buisness wouldn't care who fixed it as long as it got fixed, you have a team for a reason and you need to work with the team. It isn't a compitition it is a team if the project fails everyone fails, if the project succeeds everyone succeeds.

andrewtayloruk

There's no 'I' in team as the saying goes, you were absolutley right to implement the most efficient method of development but if you worked for me I would have liked you to take 5 and sit down with the original developer. If you really had the best solution, I'm sure the guy (or gal) would have said, yeah you're right, good call.

Imagine if you'd changed the code and what you'd done had upset something else in the code (as I said I can't comment on this specific case) which in turn introduced a problem further down the road. You said yourself the code worked but was in-efficient, are you the team leader? Is it your call to run the risk of throwing the project deadline? Perhaps you could have left the code in but made a note to bring up at the next project meeting.

It's quite difficult to get out of the lone ranger frame of mind.

You could always submit his code to www.thedailywtf.co.uk and let him regret it himself

blandarfleck

After reading your story, I began to wonder about the other side of this. Did the code you wrote work in all cases? I certainly have seen (and, maybe been guilty of) cases where an algorythm is implemented thinking it's more efficient, better, whatever, and works for new cases, but doesn't pan out for the original usage.

If, however, it's the case that the guy just got his panties in a knot, fug-im. Though it would be nice, as the previous poster mentioned, to sit down and talk with him about it, in the real world that doesn't happen. Case in point: Right now I'm working on a tight deadline for improving performance for a customer. I'm rewriting tonnes of methods, simplifying algorithms, if I had to sit down with the original developer every time I did that I'd never meet my deadline.

Now, back to my original comment: We don't hear the other guy's side of the story. Is he the 'team lead', or is there code-ownership? For example: if you're the 'process queue' guy, and he owns the 'scheduling' stuff, then I could see his case.

andrewtayloruk

Clearly in this case, you've been charged as a sole developer to re-work a lot of code, this is different in working in a team enivronment in grad school to produce a joint effort. However, in a real case scenario, if MS is knocking something out, one programmer doesn't go off and start changing code unless they've been specifically asked to, I think it's all about what's right at the time being.

Andrew

irseg

This is why I don't get along well working with other programmers. If someone else comes up with a better way of doing something than I did, more power to them. But if my way is better I stick to my guns. The best way I've found to work with someone else is to take control of one aspect of the project, let the other person/s deal with other parts, and stay out of each other's way unless their part causes a problem or vice versa.

I found that in a college environment, documenting your work and working harmoniously in a team is considered far more important than producing good code. So keep that in mind in your case, if you want to do well in class then you're probably best to keep your mouth shut and be seen as a "team player" no matter how much the code sucks. It's stupid, I don't agree with it, but that's the way it is in my experience.

theFez

wish i went to your school. all you get at mine for working harmoniously and producing bad code is bad grades all around.

Rekna, some people are just sensitive and while likely you were right to change the code perhaps you could have been diplomatic about it? Let him know you think there is a better way to accomplish something or you found a bug, and let him implement the solution. This way he has ownership of the solution as well and hopefully will believe in it as well.

Part of group programming assignments is learning to work as a group. I am fortunate right now to work with a team of programmers who all get along well, all communicate well. We get called into each other's office to look over code, take breaks to discuss things, and recognize each others' and our own strengths and weaknesses. In fact, if we get our way we will be taking over an unused conference room as a group office.

we each have our assignments and projects, but we understand the goal and recognize we are on the same team. the sales people who make promises for us to keep and frequently change requirements are the other team.

__________________
# chmod 111 /bin/Laden

AxelF

Though I also agree with some other statements here, that apply for certain situations, I can also see why the guy in this case feels that he is shown no respect.

Ideally, and in THIS situation, I think one should just make the suggestions to the other team member to try and make him see it from your point of view. Then let him do the changes himslef, or do it together. That way you will both have learned alot more. He has learned better programming from you and you both have learned to be respectful team players. In the "real" world this is actually the way it is done, until you have been assigned to work with others code.

__________________
Coffee

tropi

In my experience, coders do tend to take pride in their work and often times consider something they've created their 'baby'. If you're working as a team, then the correct thing to do is not change someone elses code, but discuss the options and make a decision together. I would also get upset if someone changed my code without discussing it with me. In fact this has happened plenty of times, and will most likely always happen at some point. The problem is that usually the person making the change doesn't see all of the reasons why one solution was chosen over another. Yes, that person may not have considered your solution, but you learn more by working through the problem than having it handed to you. I've had solutions presented to me that were more glamorous than ones I had come up with, and I'm more than happy to change the code, or even hand the reigns over if it would benefit the project. I've also been on the other end. It makes life a lot easier, let me tell you. Of course, there are always those that believe themselves to be king of the world, no matter what you say. In that case, there's nothing to do but try your best. One day you'll be that guys boss.

Stompy

I've worked on team projects before when a few classes I've written turned out to be designed in a not-so-efficient manner.

It's a career full of learning from your mistakes, so I have no problems if someone points out bad code. I'd rather swallow my pride and learn something new to become much more efficient in the future than try to keep some type of ego, deny a problem exists, only to pass up the opportunity to learn what I did wrong and why it was wrong to begin with.

It also depends on how you present it. Personally, I'd just go over the code with him step by step and point out why your method was more efficient.

The guy needs to chill out a bit

You can also generally avoid code-revision problems by commenting out why a certain method was done over another. Like the post above me said, sometimes there's more to the picture than meets the eye, but in this case it sounds like you know exactly where the trouble spot is.

__________________
I love lamp.