Subordinate Projects : I Got the Point

With part 2 of the project successfully completed, now it's time to reflect for a while. The whole idea of subordinate projects is to save time of both the designer team and the implementation team, by making each team focus only on one thing at a time, and creating parallelism in their tasks.

After this assignment project, I tend to believe that this is not the case at all, and probably in a real world situation it will be even worse. It does NOT save time.

For the designer team, it takes time to:

• write a good TDD,
• explain it to the implementers,
• make sure they understand everything, 
• follow up their progress to make sure they are on track,
• test their code and report their bugs,

And for the implementation team, it takes time to:

• understand the design,
• request changes to the design,
• understand difficult algorithms that the design might be dependent on,
• work on the bugs resulting from your lack of understanding of the design,
• defeat your "ego" or "selfish" feeling that you could have designed it better.

 Add to the above points that both teams are from two different cultures, speaking two different languages, possibly in very different time zones, and with different education backgrounds, add these and there is a huge potential for disaster I believe. It will be even less efficient and less profitable.

I have to mention here though, that if both teams, the designers and the implementers, were the same team or at least co-located, this could achieve the desired purpose of having a subordinate project (the efficiency and parallelism). This will make dealing with the above problems much easier and less time-consuming.