Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm looking for a tool for team of programmers. Generally we are split in two groups, we are building two applications on the same framework and in the same moment we are building the framework. I'm looking for a tool, which can make better our communication. The problem to solve is, one team solved a problem in first application and give some code to framework, but the other team doesn't know about this and invents a wheel. The documentation doesn't solve the problem. I'm thinking about a blog on Wordpress -- you solved a problem, so you should give a post: add some tags, description, file names etc.

share|improve this question

closed as off-topic by Corbin March, Dan Pichelman, GlenH7, svick, MichaelT Aug 31 '13 at 0:11

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – Dan Pichelman, GlenH7, MichaelT
If this question can be reworded to fit the rules in the help center, please edit the question.

11  
You can't solve social problems with technological solutions. Talk to one another –  Telastyn Aug 30 '13 at 17:40
    
How big is your team? –  Doc Brown Aug 30 '13 at 18:40
    
Ubersvn tries to help with this by incorporating a "social coding environment" for collaboration and communication around code checkins. –  gbjbaanb Aug 30 '13 at 18:57
    
Two easy steps. Put the framework under version control system. Subscribe all team members to repository updates. Now everybody will know when some feature is introduced. –  Kolyunya Sep 3 '13 at 8:40

6 Answers 6

I agree with Telastyn, but would restate it as: Communicate with one another.

The tools to communicate are many

  • e-mail
  • lync/Skype
  • SharePoint
  • wikis
  • scrums
  • meetings
  • lunch
  • beer

Use them all. Use them effectively.

share|improve this answer
    
+1 especially for the last two points on your list! –  Doc Brown Aug 30 '13 at 18:40

There's really no substitute for face-to-face communication. Since you're both working together on a common project, you should have regular communication with each other on what you're doing. This communication should be of both the scheduled and spontaneous kind.

Obviously you don't have to know every detail of what everyone is doing; that would be counterproductive. But on a high level you should be keeping each other informed about what you're doing.

This kind of communication could take several forms. I've found regular short email notifications to be helpful, assuming that your team actually reads their email. Face-to-face communication is by far my preferred method, however.

share|improve this answer

You said yourself that you don't think documentation is going to work, but isn't writing a blog just another form of documentation? Same written words, you just have to open a slightly different UI to read them and there's a good chance your team members won't read this regularly.

We had a very similar situation in the previous company I worked at where we had 3 distinct projects with very little reuse between those projects even though everybody was writing "common" utility/framework code.

The idea I came up with, but it was still a work in progress when I ended up switching jobs was to approach one (or two) senior people from the other projects and establish an informal framework team. This was done outside of official management/organizational structure, we still reported and worked on our own teams 95% of the time, but periodically we would get together and sync up.

We created a completely separate project, called it "Company X Common Components" and the idea was that when we identified truly reusable work, we would extract it from our team projects and put it into the common one. Then the common components, which had its own distribution build, were introduced as a dependency to the other 3 projects.

To share with you some of my experience, having done some of the work above and have definitely seen positive responses from many engineers, I've got to tell you it's not all fun and games.

Let's say you write a threading library and you use it in your team. Now let's say you want to extend it, so you simply extend it. But what happens if your library is shared by multiple teams? What happens if another team wants to extend your library?

What we've learned is that a) while unit tests are important, not having them in a common framework, means you can almost never touch common code once it is made common. Sure you can test the library changes with your product, but what if you introduce some edge case that breaks other teams stuff?

While documentation is important, having it in common framework is critical. You will have people who don't know you, may not even work in your state or your country using that code.

Our common framework had to have its own release schedule with its own build archives and be treated as a completely separate product. Reason for that is that release schedules of the teams were not aligned so what happens when Team A needs to modify library code, and Team B is 2 weeks from releasing theirs? We used versioning so that each team could specify exactly which version of common components they wanted to depend on. But now what happens if products from Team A and Team B get installed on the same machine? Do multiple versions of common components live side-by-side? or can we guarantee that newer version is always backwards compatible? Lots of questions.

So I'm not saying don't do it. There's definitely value in reuseability but just keep in mind that in some cases it's actually cheaper for Team A and Team B to invent their own wheels rather than having to sync up and incur the overhead that I just described.

share|improve this answer
    
+1, this is a common situation I have more than once, and you listed all the crucial points and drawbacks. When the number of persons involved reached a certain level, it is often better to accept reinvented wheels than to tightly couple teams with different aims and schedules. –  Doc Brown Aug 30 '13 at 18:47

How about repository management.

  • /TeamA
  • /TeamB
  • /Common

Components such as logging, eventing, alerting, etc. could be in common to avoid having two components to solve the same problem. Devs check common to ensure they are not re-inventing the wheel.

Each team should have a technical lead/designer that should be determining whether the code is team specific or should go into common. Tech leads/desginers should communicate on a regaulr basis with each other.

share|improve this answer

One thing I tried to get going at a previous place was to use personal objectives. Within each team some people would be given an objective to evangelise the product and code and tools and general 'good stuff' the team used. This didn't extend to just being a marketdroid though, it had to involve actively helping the other teams take this stuff and implement it successfully.

That in itself isn't good enough, it doesn't promote any incentive to take this stuff and make the effort to bring other team's practices into your own, so .. within each team some people were given the objective to bring such stuff and get in brought into the team and work with the people who are tasked to giving to understand what they've done and how to make it work for their own team.

The trick is to make people want (or need) to take, giving is easy... bashing down the NIH and reinvent-the-wheel attitudes is part what it takes, the other part is making the good stuff well documented and generally easy to incorporate into other team's ways.

share|improve this answer

If you are using .Net you should look into Team Foundation Server. (TFS). As the site states it is an application lifecycle management (ALM) solution. It is much more than a code repository. You can implement email notifications, code review, bug tracking, tasks etc... It is a pretty powerful tool. I am not sure what framework you are using, so this might not be a solution for you.

share|improve this answer
1  
How does it promote code reuse? –  Robert Harvey Aug 30 '13 at 17:49
    
I believe there are a number of code sniffers plugin for Visual Studio, but I could be wrong. In addition TFS supports Team Code review. –  Phil Vallone Aug 30 '13 at 18:15

Not the answer you're looking for? Browse other questions tagged or ask your own question.