Once upon a time, in one of the software projects, team A was collaborating with team B to develop a workflow system. The main workflow would invoke other smaller workflow - an orchestration system was the need of the day. A meeting was held and the agenda was to integrate the two workflows.
Day 1:
Team B: We have a web service and the only API 'pushMessage' should be called from your code.
Team A: Why remoting? We need a jar.
Team B: That is a very good question. The workflow is a system and not a library. We want to avoid code inter dependency. Code deployment and maintainability is easier. Service is reusable, and in this case, it encapsulates a complete workflow.
Team A: Generating web service client is pain ...(sorry but I don't remember the following words as I was rotfl; in my mind of course). We need a jar.
Team B: Generating web service client is trivial. It takes about 15 mins. We can do it for you.
Team A: Ok, let us discuss this again tomorrow.
Day 2:
Team A: We have a great idea. Let us merge the code of these 2 separate projects. We will combine all the APIs and create 1 WSDL. It will run very fast.
Team B: (After recovering from the shock) These are 2 distinct functional components. The APIs have no relation to each other. There is a clear boundary between the 2 sub systems.
Team A: It is complex.
Team B: What is complex?
Team A: Making a service call from our code is complex.
Team B: Making a service call is complex? How?
Team A: Yes, we have to make this service call inside a transaction and it is complex.
Team B: What!! When did you decide to make a service call inside a database transaction?
Team A: Today. And we have a problem. It is complex.
Team B: What is complex?
Team A: Making a service call from our code is complex.
Team B: Write 0 lines of code and you get code that has zero complexity .
Team A: Does writing 0 lines of code makes the code fast?
Team B: Yes, the code runs at infinite speed!
Team A: And can I apply encapsulation to the design?
Team B: All team members faint.
You make also like this humorous post on NoSQL vs RDBMS.
Day 1:
Team B: We have a web service and the only API 'pushMessage' should be called from your code.
Team A: Why remoting? We need a jar.
Team B: That is a very good question. The workflow is a system and not a library. We want to avoid code inter dependency. Code deployment and maintainability is easier. Service is reusable, and in this case, it encapsulates a complete workflow.
Team A: Generating web service client is pain ...(sorry but I don't remember the following words as I was rotfl; in my mind of course). We need a jar.
Team B: Generating web service client is trivial. It takes about 15 mins. We can do it for you.
Team A: Ok, let us discuss this again tomorrow.
Day 2:
Team A: We have a great idea. Let us merge the code of these 2 separate projects. We will combine all the APIs and create 1 WSDL. It will run very fast.
Team B: (After recovering from the shock) These are 2 distinct functional components. The APIs have no relation to each other. There is a clear boundary between the 2 sub systems.
Team A: It is complex.
Team B: What is complex?
Team A: Making a service call from our code is complex.
Team B: Making a service call is complex? How?
Team A: Yes, we have to make this service call inside a transaction and it is complex.
Team B: What!! When did you decide to make a service call inside a database transaction?
Team A: Today. And we have a problem. It is complex.
Team B: What is complex?
Team A: Making a service call from our code is complex.
Team B: Write 0 lines of code and you get code that has zero complexity .
Team A: Does writing 0 lines of code makes the code fast?
Team B: Yes, the code runs at infinite speed!
Team A: And can I apply encapsulation to the design?
Team B: All team members faint.
You make also like this humorous post on NoSQL vs RDBMS.
No comments:
Post a Comment