I think that specialization for software development sometime could be very problematic.
This is counter productivity when the organization becomes bureaucracy and the process becomes very rigid.
It is especially true when there are multiple interdependent teams working together.
Team A is consuming the component of the "platform" from team B.
Team B's codes needs to work with Team D to satisfy Team A's requirement.
Team F is building something using Team D's foundation.
Team G provides the utility for Team F to generate the codes on the top of the foundation.
The team A is at the end of the food chain.
If the team F' code is not working for Team A. We may blame the team F and ask the question. Shouldn't the team F test their delivery before the codes are released?
Unfortunately sometime the life is not that easy. Team F may not be able to test their code since team F's codes are working under team D's foundation.
We will need the team B's helps to make the code working even the team B has nothing to do with the code bug most time.
However, the life is not so easy, especially when we start to also use the specialized resources to work on packaging, deploying, and env issues.
Team A is facing the customers. Does this mean that the team A is responsible for making the entire thing work? If my car is not working, will my car vendor say oh sorry that is the engine company's issue, please work with them since we are only using their engine? Unfortunately my car vendor has never seen how the car drives.
I think that the definition of the inter-medium product and deliverable is every important.
The life is really miserable when we need to deal with all these - I do not know how to say it. It is not technical, not functional, not organizational, nor political issues.
This is counter productivity when the organization becomes bureaucracy and the process becomes very rigid.
It is especially true when there are multiple interdependent teams working together.
Team A is consuming the component of the "platform" from team B.
Team B's codes needs to work with Team D to satisfy Team A's requirement.
Team F is building something using Team D's foundation.
Team G provides the utility for Team F to generate the codes on the top of the foundation.
The team A is at the end of the food chain.
If the team F' code is not working for Team A. We may blame the team F and ask the question. Shouldn't the team F test their delivery before the codes are released?
Unfortunately sometime the life is not that easy. Team F may not be able to test their code since team F's codes are working under team D's foundation.
We will need the team B's helps to make the code working even the team B has nothing to do with the code bug most time.
However, the life is not so easy, especially when we start to also use the specialized resources to work on packaging, deploying, and env issues.
Team A is facing the customers. Does this mean that the team A is responsible for making the entire thing work? If my car is not working, will my car vendor say oh sorry that is the engine company's issue, please work with them since we are only using their engine? Unfortunately my car vendor has never seen how the car drives.
I think that the definition of the inter-medium product and deliverable is every important.
The life is really miserable when we need to deal with all these - I do not know how to say it. It is not technical, not functional, not organizational, nor political issues.
No comments:
Post a Comment