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.

Suppose I design a platform over a platform (say Java or Win32 or .NET), which consists of various layers like Database, User Interface, Cloud etc.

Now every team would be working to make their product, say database best and less focused on their relationship with other teams, hence resulting in various issues when doing an integration of it.

Now, these are my questions in order to achieve a stable and bug-free platform:

  1. How could one ensure that while integrating all the layers, there is less overhead involved and also is there any other way to automate this process ?

  2. Also, if one particular team is using the API calls provided by other team and if the other team is still not ready with the API calls, there comes a DEADLOCK . How to step over such situations ?

  3. Say, I want to monitor and get feedback from various teams regarding their progress. Is there any automation available for such activities ?

share|improve this question
2  
Re 2), it is not a deadlock, just a (one-way) dependency blocking a team's progress. It would only be a deadlock if both teams were mutually blocked by the other. –  Péter Török Jan 25 '12 at 13:46

3 Answers 3

How could one ensure that while integrating all the layers, there is less overhead involved

Performance measurements and profiling.

and also is there any other way to automate this process ?

No. Good design is really hard work.

if one particular team is using the API calls provided by other team and if the other team is still not ready with the API calls, there comes a DEADLOCK . How to step over such situations ?

Sadly. You can't. The team that is producing the API calls needs to break the API suite into pieces and deliver the important piece first.

The team that is consuming the API calls needs to break their work into pieces based on importance. They need to focus on the important pieces first. They need to communicate their priorities to the API producers.

Say, I want to monitor and get feedback from various teams regarding their progress. Is there any automation available for such activities ?

Do Not Automate this.

Actually talk to the actual people every single day.

Have a daily Scrum meeting within each team. This is 15 minutes that will dramatically improve the project.

Have a daily Scrum-of-scrums among the team leaders. This is 15 minutes that will dramatically improve the project.

share|improve this answer

Your team sounds like it suffers from poor management and other problems. In a typical Agile project you will see that sub-teams of technical specialists (Team A only does Database, Team B only does Web Services, Team C only does GUI, etc...) is frowned upon.

Ideally a team should exist to write software that meets user needs (User Stories). No other subdivisions of that team are acceptable. Every resource on that team should be able to be assigned a user story, and complete it from Database to GUI across all layers. Sure some developers have strengths and weaknesses, but the team should be able to help each other out where needed.

Your team is broken up and there is a lack of coordination between teams now. I know that restructuring the team may be difficult or impossible, so here are some other suggestions:

  1. Answer 1: A good way to work out integration issues is to write a suite of integration tests that verify the proper communications between each layer. If the integration tests are done correctly, they will notify if there is a failure at one of the layers. Perhaps the web services were never deployed? Perhaps the Test environment didn't get the latest database changes deployed? Etc...

  2. Answer 2: You can't force the other team to complete before you do. Integration tests will tell you ahead of time if the other team has completed or not. Before this point however you should write independent Unit Tests for the code at your layer, so that you can verify your code and functionality before the layer you depend on has completed.

  3. Answer 3: You should have issue tracking, or other project management tools that are publicly available to every member of the team. As a developer, I should be able to look in the project management tool to see which tasks and issues are Open, In Progress, or Completed.

share|improve this answer
1  
I think it largely depends on project and team sizes. If you have 10M LOC and 200 developers, they must be separated into subteams, otherwise the sheer amount of the necessary communication and learning overhead is going to kill you. Of course, the separation can be done in different ways, and communication and syncing between the subteams is crucial. –  Péter Török Jan 25 '12 at 13:50
    
@PéterTörök Just based on my professional experience so far, I think teams that large are an exceptional case and the software must be extraordinarily complex. The largest team I have worked on had 1M LOC and about 25 developers and that was an ERP system O_O –  maple_shaft Jan 25 '12 at 14:25
1  
Indeed, such large projects are an exception. Nevertheless, they still exist, and are important. IMHO even with 25 developers, subteams may be a good idea to reduce communication overhead. Of course these subteams should not be too rigid, there should be no thick walls between them. –  Péter Török Jan 25 '12 at 15:00
    
@PéterTörök Well in that case the nature of the software made it natural to split everybody up into teams of 3-4, because everything was so modularized and only a small percentage of user stories overlapped. But with 200 developers, I wouldn't even know where to start! –  maple_shaft Jan 25 '12 at 15:11

1) How could one ensure that while integrating all the layers, there is less overhead involved and also is there any other way to automate this process ?

You should have an architect group for the overall system. But make sure they don't just design some interface. They should facilitate discussion between the teams and the interface should be only settled on if both sides agree it's reasonably easy to work with/implement. The design also needs to be flexible, so that if any team asks for changes, they need to be promptly discussed with all concerned teams and agreed upon or rejected.

2) Also, if one particular team is using the API calls provided by other team and if the other team is still not ready with the API calls, there comes a DEADLOCK . How to step over such situations ?

If you agree on how the interface should work in advance (see previous point), than you can create mock version for unit tests or at worst program to specification for a while.

3) Say, I want to monitor and get feedback from various teams regarding their progress. Is there any automation available for such activities ?

As S.Lott already said, you have to talk to the people, every day. Have a daily scrum meeting in each team and daily scrum meeting of the team leaders (with the overall project leader). I'd say the architects should be at least on the team leaders meeting, perhaps even on all the meetings, so they are always aware of issues that may affect the interfaces.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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