One Application, One Location and a Few Programmers...

[ayozzhero]

This is not about programming actually. It is about how a group of programmers work together to build an application.

In my environment, task or modules or forms are distributed between programmers to complete an application. The big problem is, it is very hard to control them. Currently, every completed .vb file is stored in one place i.e server. But when a programmer forgets to upload his updated forms/module it will ruin everything. It gets worse when two or more programmers coincidently make modification to the same file.

How/ what is the correct way of handling multiple programmers? Is there any software to solve the prob... any mechanism or good practice.

Any idea/ experience sharing is appreciated.

Thank you.

 

[Steven McDonald]

The way we do it here is that each programmer is responsible for his two or three forms, if someone else wants a change then he tells the relevant programmer where and WHY the change is neccessary. always give a week for integrating the forms together though, as certain bugs WILL always appear. It is basically impossible to write an error-free app first time round!

 

[kulrom]

Hi,
Actually the Q is: what is the best way to organize and track programmer work.

First off, if you are the “MAN” you should know that Chief programmer makes all important decisions so he/she (you in this case) must be an expert analyst and architect, and a strong leader as well.

Probably all your programmers have certain task and now you only need to track their work. But, no matter how you organized them you’ll be faced with many problems there trying to track assignments, estimates, progress … i.e. many programmers haven't worked together before; each programmer comes from a different school etc. Anyway, frequently measure progress and adjust process as necessary Standardization of work outputs is good coordination mechanism E.g., UML diagrams, standardized unit tests, etc.

Btw, you asked about the tool. Well, the magic isn't in the tools. It's in 3 questions:

1. Does everyone care about the schedule?

2. Do they understand the system being used to track?

3. Are they willing to help the team track the schedule?


If the general answer is yes to all 3, the team will help you figure out the best way to do the tracking, and can you to overcome any deficiencies you find in tools. If the answer is NO to one or more of these questions, you'll have problems no matter how great the tools are.

However, if you think you cannot find solution without additional help you could use MS Project http://office.microsoft.com/en-us/FX010857951033.aspx in my experience one of the best tool for small projects and small number of users.



Cheers

 

[jmcilhinney]

Noone's mentioned source code control specifically. It doesn't matter what the rules are if people don't follow them through laziness, stupidity or whatever. Surely one of the most important issues in a multi-developer environment is properly implemented SCC. I use SCC in an independant developer scenario, although it tends to be mostly for version control in my case. I used to work in an office with other developers and we used Visual SourceSafe. Not the best tool around, from what I've read, but does come packaged with the higher-powered versions of Visual Studio. I've heard several mentions of something called Vault that is supposed to be very good.

 

[TechGnome]

jmcilhinney hit the nail on the head... Source Control.... that's how we manage it here. It allows us to keep track of what changes were made by who and when. The idea of people having "assigned" parts to work on and they are the only ones to change anything in there is a bad idea. And here's why: If that person is allowed to do what they want, then get hit by a beer truck.... there's no one that will be able to take over. You'll also have no idea what they did. And odds are there's no coding standards so you may end up with cryptic coding methods that don't mean anything.

ENFORCED Standards and Source Control (and communication) are the best weapons against rogue developers in a team environment. Speaking of standards and SC, we don't allow something to be checked back into VSS until it is done and is compilable. And since VSS marks who has what checked out, if something is missing, we know whose desk we need to go sit on.

Tg

 

[kulrom]

... if something is missing, we know whose desk we need to go sit on.

Tg

If you can resolve the problem, then what is the need of worrying?
If you cannot solve it, then what is the use of finding who is responsible.

Don't you think it's much better if you preserve it to happens than if you find it in the later stages and ask programmer for responsibility?

Cheers

 

[jmcilhinney]

If you can resolve the problem, then what is the need of worrying?
If you cannot solve it, then what is the use of finding who is responsible.

Don't you think it's much better if you preserve it to happens than if you find it in the later stages and ask programmer for responsibility?

Cheers

I think that what TechGnome means is that if a code file is supposed to be complete or is needed and is currently checked out, the SCC system will tell you who has it. Then you can remind them to check it in if they have finished with it or tell them to get a move on if they haven't. These situations have both occurred in my own experience and I'm sure they happen all the time. The beauty of SCC is that the tool takes care of the details and you don't have to rely on people to record what they are working on. You just have to rely on them to do the work, which is unavoidable I'm afraid

 

[kulrom]

Lucky you that you haven't experienced it (obviously you were cooperating with only good programmers), but trust me, you can fall in such a trouble with some programmers that neither tool could help you out

Cheers

 

[TechGnome]

jmcilhinney sort of got it..... let's see if this description wroks, as this is how it works in our world. Ours is a one app, 12-15 developers, hundreds of DLLs and OCXs (don't ask, it'll make my head explode describing how it works.)

A client will call in with a problem with the app. Their account manager researches it and, yup it's broke. They then log a problem ticket and it gets sent to the developers. At some point a developer is assigned the ticket, for simplicity let's say that's me. I get the ticket, run a report that gives me all the details, and I start getting the proper build & component. I open VB, open the main part of the app, then add in the project in question (each screen is an OCX that has it's own project). I run through a test case and figure out where the problem is. Once I find it, I check the file out of Source Safe and begin the modifications. Now, in the meantime, no one else is allowed to touch that file, other stuff can go on in the project, just not in that file.

I get done, run my tests, and it all seems OK. I then check the file in, open VSSm find the project and label it with the ticket number. Then the ticket gets sent to test & QA. Since testing always takes longer, four months later, they finaly get around to testing it. At which point they find something wrong with it. By looking at SS, we can who did the change (me), when (4 months ago) and why (ticket number). By doing a diff, we can also see what change was made.

Ok, now QA should already know who did the change and what the change was since they have the ticket in hand. But 6 months after that, long after it's been released, no one is going to remember that ticket number. And let's say that Joe is assigned to the task. He looks and wonders why something was done a certain way (or at all for that matter). Byt checking the history, he sees that I was the one that made the change, and what the ticket number was. He can then look up the ticket and stop by my desk to ask me about it. It doesn't necessarily mean that it's wrong, but it's simply a case of learning more about the system and why somethign was done the way it was.

Kulrom - if you are working with "bad" developers, then something needs to be changed. it sounds like these are people who aren't being held accountable for their actions (inaction?). And granted, the process is only as good as the people willing to following it, but then they need to be given incentive, which it doesn't sound like they do. Unfortunately I think it's rather difficult to do once things are up and running, and that it's better to implement this kind of stuff early on. But if the team isn't flexible enough to roll with new changes.... then maybe it's time for a little organizational shake up.

Tg

ADDED: Also, I have worked with bad and good developers. And yes, despite the tools, we've had some pretty big cockups, and even the tools in some cases made it worse. But you work around it the best you can.

 

[ayozzhero]

Lucky you that you haven't experienced it (obviously you were cooperating with only good programmers), but trust me, you can fall in such a trouble with some programmers that neither tool could help you out

That is what happenned to me here. We (programmers) are helping people to solve their problems... yet we can never solve the 'human factor' in our own office. Up to now, I have not use any software to control the version, though it is the major prob... It seems like printed rules and human enforcement doesn't work well here. I once succeeded in controlling the version... but with people come and go, I am here all helpless.

From all information above, can I conclude that one form/module is to be owned/coded by only one programmer?

Anyway, thank you guys for sharing... other ideas/experience are still welcome to enrich knowledge.

 

[jmcilhinney]

An SCC program is ideal for version control also. As I said, I use it for that reason specifically. I used to save a copy of each release version and then go back to that if I had to fix bugs, etc. in that version specifically. SCC handles all this type of thing as well. You can label a release version and then refer back to that labelled version specifically at a later date without affecting the flow of any current work. Also, as TechGnome alluded to, you can use the SCC program to instantly show you the differences between two version of the same file. All additions, updates and deletions are generally highlighted in a different colour. Too easy! Again, really bad people will find a way to stuff up anything. SCC will generally keep those who are just a bit lazy, sloppy or forgetful in line. There's also a new version Visual SourceSafe due with VS 2005.