The Principle of The Fire Ball

Let’s say “Hi” to all guys , sorry girls we are talking about software you are excluded from this conversation, which will read my first post. I think that every developer will find something from his experience in this post. Many developers face a problem with their managers. I will try to share my observations with you. Probably you meet almost the problem like this every year. Let’s say you are working in a big company with a serious management stuff. One day you have faced a serious problem with architecture of the product. It was unsolvable from your level of competence or probably you didn’t have the rights to solve it on your own. So you rise the problem to the upper level which is your team lead. Your team leader understood your point but he decided that it wasn’t reasonable to take the responsibility of this problem on his shoulders because you had to meet the deadline and rise the problem on the product manager’s level. The product manager is not so technically dipped in the details and he decided to be discussed on a meeting with product’s software architect. And tada …  you had a meeting with product’s architecture , product manager, and  your team lead. The meeting started with a long speech from your team lead that there was an distributed asynchronous problem which probably needs decision on a design level.  The manager of the product didn’t see the light in the tunnel also didn’t want to take the responsibility of the decision also he needed to meet the product’s dead line, so he asked the software architect to analyse the the problem. The software architect didn’t like to be considered as ‘incapable architect’ so he analysed the situation and explained that the problem could be solved with synchronization on a higher level and that would be a piece of cake for you( the developer).

The final resolution to the problem was that “We could decide a distributed and asynchronous problem with synchronization on a higher level !”.  Now let’s imagine the picture in the context of a fire ball that you have fired, actually you have found a serious architecture problem before the product release. You couldn’t response to the problem with some new supper duper implementation so you threw the ball to your team lead. Your team lead understood you but he didn’t  want to take the responsibility before the deadline and to extend the development more than a week so he threw the fire ball to the product manager. The product manager was waiting his promotion , and throw the fire ball to the software architect. We already knew that the product architecture didn’t want to be the victim of the product release. The software architect threw back the fire ball to you the developer and you were on the initial state.  The result of this meeting was a non stable product release and dissatisfied customers. Somebody should have asked who cares ? Yes dude you are right but your salary is function of your product , so if your development is disastrous your salary will become a black hole sooner or later!

From time to time I remembered a joke which could reveal fully  “The Principle of  The Fire Ball” more clear.  A helper of mason asked him why he kept layering bricks when the wall is twisted and the mason responded that the plasterer would straight it.  After the mason , plasterer started working on it and mason’s helper also ask him why he was working when the wall is twisted. The answer was because the painter would set it up straight. When the painter was working ,his apprentice also asked him why he was working when the wall is not straight. The painter explained him that the owner would set it up straight.

The conclusion is managers don’t throw the fire ball when you can handle the problem. The ball will come back to you sooner or later, it’s your destiny. You are owner of the product! One advice to developers throw the fire ball as quick as possible to the managers or better you could replace the fire ball  with lava ball!

P.S. You could investigate why the Toyota’s worker can stop the production line at any time.

Thanks to my colleagues that helped me with this principle!

5 thoughts on “The Principle of The Fire Ball”

  1. I think that the problem is in missing ( or not following ) the product specifications. Let’s take the civil engineering for example – why such situations are very rare there – I’v never heard about a worker that even have access to the architect – why ? May be because in civil engineering there are strong specifications of everything that will be used during the build process – even if the given detail is trivial, actually it is not trivial in the current project, in the current configuration of details.

    1. Actually the software engineering keep working on its best practices and you know that there is no “The Bible of the Software Construction” like in the civil engineering.

Leave a Comment

Your email address will not be published. Required fields are marked *