tags:

views:

120

answers:

4

I am just asking for an advice here..

What would to you if you come to work on Monday, after a very extensive Friday of working all day. And you found out that someone in the team, changed all the code during the weekend, and even changed UI stuff that was already approved.

The project is a very very different project now.

I am really uncomfortable with this, I think changing everything should be a decision of the whole team, not just one individual guy.

But I wanted to know what you guys think, it is just me that really cant stand this kind of things? or do you feel the same way?

+1  A: 

This points to a lack of specification and leadership. You should agree on what you are building beforehand (including UI), and then build it. These should not be arbitrary decisions made by lone developers or you will all be moving in different directions.

If there is a Team Lead, this is an issue for he/she to resolve. If you do not have a Team Lead, you need one to facilitate making the inevitable many small design decisions that will crop up along the way, and to make sure the overall vision is being adhered to.

RedFilter
we made a plan for everything, even for the UI. But We do not have a Team Lead or a Lead Developer. but the way it was made before the changed was a group decision
GerManson
Group decision to undo the changes then! Does this guy have excellent martial arts skills or something? Overpower him!
Adam Crossland
A: 

If the expectation is that anyone can change any code, it should be fine - try not to be possessive of code. On the other hand, any project without change controls where someone would completely change code without checking with others has serious problems.

Paul E.
While I agree in principle that being possessive of code and letting your ego get hurt by someone else's changes is a bad idea, in this case, it sounds like OP's team desperately needs someone to be possessive of and willing to enforce the group's vision for the product.
Adam Crossland
+1  A: 

I would be deeply concerned that my project team lacked any structure, accountability and management. Cowboy coders are lousy teammates and will often spell the death of morale and productivity.

Do you have a manager to whom you can address these concerns?

Adam Crossland
sure we do. but he wasn't aware of the changes either
GerManson
"Cowboy Coder" -- Good term. I'll have to remember that one...
Pretzel
Shouldn't the team lead be able to make the decision to roll back the changes made by Mr. Cowboy? You guys are using some kind of source control, right?
Adam Crossland
Yes, we must continue working with the changes from this guy. he combined the last check in with needed features and the refactor of everything, talking to him it seems that he didnt understand the code, so it was easier for him to do it all over again.
GerManson
@GerManson -- you have a right to be upset -- very upset -- with this turn of events. However, it is foolish to meekly accept this lone coder's incompetence as being the deciding factor in your project's fate. The changes can be rolled out, and the things that he wrote that need to be in the project can be extracted through creating diffing or simply redone. It is impossible to accept that one man's bad weekend of coding can change the direction of the project forever. Be a leader and talk some sense to your manager.
Adam Crossland
@GerManson: So, which is easier: reject his changes and tell him to do them right, or let him run the project and break agreed-on functionality? If you think you must continue to work with that guy's changes, you've lost already, and my only advice is to find a shop that's run maybe a tenth competently.
David Thornley
Agreed and echoed, @David. Ger, think about how absurd it is to accept the wholesale changes that someone made to a project because he didn't understand it. How can that possibly ever result in a successful project? Are you and all of the rest of your correctly-behaving team mates just going to shrug your shoulders and let this cowboy kill your project? Better to cut your losses now if no one is going to nut-up and do the right thing.
Adam Crossland
A: 

Oh. You mean he wrote a large number of unit tests, refactored all the code, provided better method and instance variable names, documented it all, wrote a rationale explaining why and how he made these fantastic improvements and why it was not possible to explain what he planned on doing before the weekend, re-ran the build-, unit-, performance- and acceptance tests?

Oh, that's great.


But don't you guys pair-program and use sustainable pace? It sounds like it might make sense to make that obligatory for a while. Oh, and if the changes were done a bit different, you might want to simply undo them and continue where you was last friday. Send a short mail to your project leader/manager asking him for an intervention.

Stephan Eggermont
He is always a late night programmer, he always ends up doing work at weekend, he didn't understand the code and it was easier for him to do it all over again.
GerManson
@GerManson -- that's insane. Just because this programmer prefers to keep company with vampires does not mean that he gets the last say in making decisions for the project, especially if he doesn't understand the project. It's *insane.*
Adam Crossland
@GerManson: so this is expected behaviour? Then there is not necessarily a problem, unless the code is bad. Is the new code better (does every teammember understand it, and see above for some criteria)? How do your teammates like his behaviour? And management?
Stephan Eggermont