There is a very old and famous TV serial in Bulgaria “On Every Kilomerter.”.  It’s a film for Bulgarian Guerrillas during The Second World War. I haven’t watched this film from more than 20 years! But today when I heard my colleague to mention the word Trac for the 99th time for the last 2 weeks, I remembered  the phrase of a hero with a nick Mitko the Bomb.  In the film Mitko The Bomb blurts out “Why don’t we throw a hand grenade!”  in almost every situation during the whole serial. Probably I have to give a nick to my colleague “Nick The Trac” ! It’s funny but sometimes I notice that many software developers use the guerrila tactics for the software development. What I mean is the fact that many people don’t want to get the bull for the horns and make effort to find a good decision or to implement the best code according to their capabilities. So they respond with duty action or phrase. For example if you have to prepare mockups for the meeting with the clients these week you start writing tasks in the Trac or creating a new division of components and insert a new component with the genius name “Questions to the client”.  Now Please Go Back and Reread The Bolded Words In The Previous Sentence!!! Do you think it’s reasonable to loose almost a day for talking with all possible managers and do stupid actions like this with organization of the Trac, when you don’t have enough time to prepare the mockups? The interesting part is that you report that you made reorganization of the Trac and complained in front of the managers about lack of time to make all mockups and you need somebody to help you !!! This tactic do its job 100% every time. Even you offer to the client to install him a Trac or transfer all problems and questions to the client in csv format to be transferred in their tracking system !!! If you think that the example above is not enough I will give another one with my other colleague. The nick I gave to my colleague is “Kevin The Forum”. Kevin the forum couldn’t work with people and doesn’t listen the senior people above him at all. So every time when Kevin the forum meet a minor problem, he posts a question in some big forum and report to the manager that he met a serious problem and was waiting for response from the forum !!! Please read again the last sentence I know that I am insolent but I consider that this is very stupid action to ask the world for a stupid question before you ask you senior who has 10 to 20 times more experience than you in these domain. If you think that this is not enough probably I have to mention the colleague with the nick given by me “Dan the public static member” who thinks that he thinks that he knows OOP because he is developer for 10 years and use thoroughly public static members. Please re….. !!! The interesting part is the daily report to the manager that actually he was ready but had to make some improvements !!! Have you ever heard this phrase ? Yeah, I know you heard it almost every day. What could you say to a colleague that he alleged to know design patterns but he didn’t know design pattern names ? Please re … !!! I couldn’t understand why the software developers use one and the same guerrilla tactic and expect every time somebody to do their job, to make the design, to implement the new decision and so on.  If I have to mention the idea of Taiichi Ohno that if you look in reverse order from the client side the software process you will see that the product of software developer is the source code not the Trac reorganization,  writing posts into forum, or some excuse that you have finished the task but you need time to polish the task or mockups a day or two.   Please re…. !!!

I will finish my post with an idea of Bob Colwell that every craftsman could be discerned by the tools.

P.S. Now what do you think regarding guerilla tactics ?

I excuse of my bad English ! At the moment like this I sorry that I am not proficient in English to depict the situation and my feelings in depth !

!!! GOD HOW MUCH PAIN THERE IS ON THIS EARTH !!!

Recently I worked on a server side project. And I noticed this snipet below :

public class DBConnection implements Connection {

private DBCConnectionPool pool;
private Connection conn;
public DBCConnection(Connection conn, DBCConnectionPool pool) {
}
}

I was very curious to see the reason for pool reference in a connection pool. I saw very interesting situation. Can you imagine to have a connection pool which stores DB connections. Also every connection invokes method of connection pool “return connection” with parameter “this” just to return itself to the connection pool. Actually method “return connection” invokes virtual method “release” to the same connection through the passed parameter “this”!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!NO COMMENT!!!!!!!!!!!!!!!!!!!!!!!!!!!!

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!