Picture this. I am back form Cape May with my family, we went to a restaurant altogether once. 18 of us, 10 adults, 8 kids from 5 families.
When we showed up they opened a new room for us. We sat down at three tables, one kids only, one adults only, one mixed. As you can imagine, a waitress nightmare.
When we started ordering we learned that they could not make 5 invoices, they could not simulate that we were using 5 tables, we would not have eaten at the same time (I did not get that one).
Seeing this I decided that I would take the bill and split it myself.
This is clearly a case where one's process has created a mess on another one's process. The ordering process had to win over the paying process.
It took me a few minutes to categorize the orders by family and and split the bill appropriately. Not a big deal but a clear annoyance when you are the one paying.
Could the waitress have avoided me this? I still think so. But what has happen? It is simple: a lack of consciousness that a failure at one process causes negative consequences onto another process down the stream.
This is something we are careful with at Macadamian. One critical area where this could dramatically slow down a development team is with the patch creation and code review processes. The former flows into the later. A failure at creating a high quality patch will add delays and waste in the code review process. We teach our joining team members about this in our Dev-101 training session.
Thou shalt create a high quality patch for the code review to go smoothly.
This sound like a no brainer. That said, it's easier to convinced someone of something when "there's something in it for me". In this case, a good quality patch will reduce your chance of rejection and speed up the code review process. Which is clearly in your advantage.
What was in it for the waitress? Simple, a more satisfied customer will leave a bigger gratuity.
When we showed up they opened a new room for us. We sat down at three tables, one kids only, one adults only, one mixed. As you can imagine, a waitress nightmare.
When we started ordering we learned that they could not make 5 invoices, they could not simulate that we were using 5 tables, we would not have eaten at the same time (I did not get that one).
Seeing this I decided that I would take the bill and split it myself.
This is clearly a case where one's process has created a mess on another one's process. The ordering process had to win over the paying process.
It took me a few minutes to categorize the orders by family and and split the bill appropriately. Not a big deal but a clear annoyance when you are the one paying.
Could the waitress have avoided me this? I still think so. But what has happen? It is simple: a lack of consciousness that a failure at one process causes negative consequences onto another process down the stream.
This is something we are careful with at Macadamian. One critical area where this could dramatically slow down a development team is with the patch creation and code review processes. The former flows into the later. A failure at creating a high quality patch will add delays and waste in the code review process. We teach our joining team members about this in our Dev-101 training session.
Thou shalt create a high quality patch for the code review to go smoothly.
This sound like a no brainer. That said, it's easier to convinced someone of something when "there's something in it for me". In this case, a good quality patch will reduce your chance of rejection and speed up the code review process. Which is clearly in your advantage.
What was in it for the waitress? Simple, a more satisfied customer will leave a bigger gratuity.
Posts
