Sign in to follow this  

[Need an advice] What can you do if teamwork does not work

This topic is 4268 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi Folks, i am desperated and would like to here some opinions/advices/hints. My situation is as following: I'm working on a J2ME-application for which i'm also responsible as a project-leader and i've got a deadline for the first milestone next week. Beside me there is another person working on the project. But regrettably the communication does not work the way i would like to. A brief summarization how i would like to see teamwork: - working on the same codebase - same technical requirements - every person has it's own task for which he is responsible - code is written in a way, that another person can work with it in a short amount of time Sadly, none of the above points apply to my current situation. At the beginning of the project we decided to use MIDP2 but my co-worker uses MIDP1 (and re-implemented the whole functionality which is provided by MIDP2). For every single task he created a new project. So most of the needed functionality is somehow available, but not in one single project... so working on one codebase is also not possible. In his code is almost no (helpful) comment and the code is not readable at all. Example: private void addNewRole(int id, int j, int k, int l, int i1, int j1, int k1, int l1, int i2, int j2, int k2, int l2, int i3, int j3, int k3) Or another one: dt++; int k2 = YMPos; k2 += T + C * dt; if (k2 < 0) { dt = 0; T = 0; k2 = 0; } YMPos = k2; As it wouldn't be enough, i'm only allowed to work 20 hours each week, but my co-worker spends about 60 hours in the company. Then we have two different mothertongues and we can only communicate in english and we also have totally differnt mentalities. I was spending hours of talking with him and every time I thought he get my point and we had a roadmap how we are going to proceed, he was ignoring one hour later our conversation and made things in his way. Even other co-workers couldn't help me with my problem. And now I would like to know what you would do if you would be me? At the moment I'm thinking about starting from scratch at home tonight because most parts are available (somehow / somewhere), but making out of all the single projects one project, with readable code, using the specified requirements. I really have no clue how to deal with this situation anymore and even my motivation is quite low at the moment. Would be nice if you could give me some advices. Thanks in advance...

Share this post


Link to post
Share on other sites
Well, first of all, youe are in a very difficult situation, as I understand you're the project-leader so if you think you have tried every posibility to establish a fluid communication you must try the following:

-Inform everyone at the project about the situacion in a meeting where you and your co-worker were present. A final solution about the problem must be the output of the meeting.

-If it fails....tell the boss, you have tried everything.

-If there's no boss...radical measures.

Share this post


Link to post
Share on other sites
* if you have a crucial deadline and you think you won't make it, inform the boss/clients that the build will be delayed at least 3-4 days before it, otherwise the situation can get REALLY painful !

* evaluate in terms of time replacing your co-worker with someone else over writing things yourself from scratch, and choose the better option.

* if you have (any) working build, you can use it for the deadline presentation and do the changes afterwards !


and the other stuff as Juan Diego added !

Share this post


Link to post
Share on other sites
I'm not in a lead programmer position or management role, but I would try assigning him to some other, non-critical projects until after the deadline, if that is possible under your circumstances.

You don't have to be blunt telling him he writes awful code, but you could give him a bunch of hints in this direction (put some software engineering books on his desk ;)), so he can improve his quality on the fresh project you assign to him. If he doesn't read the books or generally just doesn't show any signs of improvement then fire him.

Share this post


Link to post
Share on other sites
Thanks for the replies.
I'm not in the position to fire or replace him. But I had (again) a meeting this morning so that I get some help from co-workers in higher positions. Hopefully this helps.
(In my next life I'd like to work at a fast food restaurant... the deadlines making burgers are not that critically ;- )

Share this post


Link to post
Share on other sites
If the deadline is a week out and you do not have a fully functional implementation at this time you have already missed the deadline.
If you can only work 20hrs, then there's nothing you can do now. I'd update my resume. You will have to rely on him to pull it off with the work he has done.
Often in these circumstances they will allow you to slip the deadline a certain amount. I cannot gauage the project from here, but sometimes it's important you have something working, other times you are best off taking more time to do productive work. In my experience panic-mode development waste a lot of resources accomplishing minimal work that you can take forward (sounds like the case here.)

If the project continues:

During the meeting keep notes about what you agree to do. Make a list of "Action Items", what is supposed to be done, who is supposed to do it, and when it is suppose to be done by (realistic completion dates are critical to working efficently), and what is suppose to be delivered (i.e. deliverables). After the meeting email the list of action items to everyone in the meeting. If you have a problematic person include thier supervisor. Follow-up a day or two later with the action items and see that progress is being made. If they do not do what you ask them to, do not assign them any new tasks until they complete the previous one. Once the task is late email them and thier supervisor every day (or every hour if it warrants that kind of attention) until it is done.

You ought to have a plan that says what needs to be built and estimate for how long it will take and when it will be done by. Then when a component is not ready on time you can also assess what impact the delay has on the completion date.

Setup the release project and put it under source control. Make it his responsibility to integrate his code into it and one of the deliverables is that you can check-out the project and build it at your location.

It is not always obvious to workers what thier boss wants them to do, and often they find themselves second guessing priorities. As a manager you need to make very clear what needs to be done and it what order. He may not think its important to integrate the code right now, maybe he's in panic mode just trying to write code that does something. If verbal communication is problematic, it is critical things are reinforced with written communication.

My personal pet-peeve is "It's done but...". If there's a "but" it's not $*(&!# done.

Share this post


Link to post
Share on other sites
Andrew Rollings has written something about the different types of persons you can expect in any organisation. Sadly I lend my copy of the book to some professor here so I can't look it up but I can remember there were types ranging from the "maverick" to the "primadonna" each with its own unique behaviour and strategies for recognizing and dealing with such persons.

From your collegue's cryptic coding practices and creating numerous projects behavior I think this guy just would like to program on his own, rather then share his code and let other people work on that. Thats cool, he can be an indie game developer on his own but your boss should recognize such persons can not be shoehorned in any organisation no matter how brilliant they are. Usually such persons are quickly "promoted" to the research department of companies so their knowledge and expertise can still be used.

Share this post


Link to post
Share on other sites
Quote:
Original post by eelke_folmer
Andrew Rollings has written something about the different types of persons you can expect in any organisation. Sadly I lend my copy of the book to some professor here so I can't look it up but I can remember there were types ranging from the "maverick" to the "primadonna" each with its own unique behaviour and strategies for recognizing and dealing with such persons.


Not Rollings, but you can expect to see a number of people from The A to Z of Programmer Predilections in any organization.

Share this post


Link to post
Share on other sites
Thanks again for the replies (especially the extensive one from Shannon).

Yesterday we sat at one computer to merge the code somehow to one codebase. Due to fact I left the company earlier then him yesterday, I told him to check everything into subversion. What he even did! He also had a conversation with the supervisor.

But this morning as I had a closer look at the code, it was full of magic numbers. So I asked him, what this should do. Tooks him about 10 minutes to find out. Great! After fixing that and telling him that I never want to see any magic number in his code, I've told him to implement feature XYZ. After a short discussion he agreed and I really thought that he get it, that feature xyz has priority.

When he left, I asked him: "Have you checked the code into subversion?" And then... ARGH... He told me, that he started a new project to make some research on feature ABC. I'm going nuts! Maybe I relly have to ask every 10 minutes what he's doing. Here in Germany it's already half past eight and I'm still sitting in the company. Tomorrow I will have again a conversation with the supervisor...

I already worked with a lot of different persons. But something similar like this one I haven't seen yet (and hopefully will never see one again).

Going back to work now...

Share this post


Link to post
Share on other sites
Another thing is not to press them too hard to develop code your way. People can be much more productive working the way they like to. No sense forcing him to use Eclipse if he likes using CodeWright.

Build prototype/research builds is not a horrible idea either. We routinely do this to experiment with new things. What's important is that he integrates the fruits of that work into the main project. Particularily if he is not accustom to using source control, or not a decent source control tool like subversion, then creating seperate projects to try things could be a good habit he learned in that environment. Give him time to change. Some time later on show him how to make use of the source control tool to create a sandbox branch and how to use the diff to revert changes etc...

An example from my team is one of them would always comment out blocks of code they changed and leave them languishing in the source files. Without source control this isn't a bad idea, you can look and see what the old source was and compare it to what you have now and revert to it if things go awry. With source control it screws everything up because diffs between revision are no longer useful (everything becomes an add, no replacements). After I showed them how to use the diff/revert/etc... features of the source control tool they stopped commenting out code.

Share this post


Link to post
Share on other sites
Quote:
Original post by Shannon Barber
Another thing is not to press them too hard to develop code your way. People can be much more productive working the way they like to.


In general you are right. But if I am working in a team, I expect some rules that every one has to follow:
- comments to every method (just what the method is doing, so that I can use it)
- names of variables and constant should represent the meaning (and not names like a, b, c, a1, a2, a3)
- no uncommented magic numbers or better no magic numbers at all
- sticking to the technical specification and not using your own
- working on the tasks you agreed to work on

With those I would be already pretty lucky.

Quote:
Original post by Shannon Barber
Build prototype/research builds is not a horrible idea either. We routinely do this to experiment with new things. What's important is that he integrates the fruits of that work into the main project. Particularily if he is not accustom to using source control, or not a decent source control tool like subversion, then creating seperate projects to try things could be a good habit he learned in that environment. Give him time to change. Some time later on show him how to make use of the source control tool to create a sandbox branch and how to use the diff to revert changes etc...

I also agree that research builds are a good thing. But in my case my co-worker DID already research on the feature I asked him to implement into the main project. But he was working the whole time on another feature what was absolutely not his task.
Beside that he was shown before how to use our source control tool.

All in all it would be not that bad if he would work on the task we need at the moment and not searching on his own for tasks that seems interesting to him and what we might need in 6 months. Fact is that he's not getting his work done he was assigned to (and which he agreed to).

Share this post


Link to post
Share on other sites
I'd consider this a discipline problem. The "coworker" seems to do what he wants without caring for deadlines and even direct orders, not only providing no value but also costing some effort to others.
The hard to maintain code, although expensive and maybe fatal in the long run, is much less immediately dangerous for the project.

The main short term solution I see is switching to a very short leash. Instead of just telling him to integrate the changes or work on XYZ while you work on ABC, sit at the same computer and work together; you should be able to extract some information from him and an useful version of the software from his copious output. Stop trusting him.

After the deadline, investigate the reasons for the communication and discipline failure. Some can be guessed by your accounts.

- Do you lack authorithy for organizational or personal reasons? Isn't he afraid to be punished for his insubordination, or at least classified as a troublemaker or shamefully coerced?

- Do you have a loose and permissive approach to management? For example, in no sane environment someone could use MIDP 1 in a MIDP 2 project and waste effort "reinventing the wheel": why did you allow that?

- Does he think you are a moron? A normal person discusses orders and grumbles to convince someone else that they are making a mistake. If he just disobeys without talking, probably he thinks that not only he knows better, but also that talking to you is a waste of energy and/or that you cannot understand what he is doing.

Good luck!

Share this post


Link to post
Share on other sites

This topic is 4268 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this