Karmona`s Pragmatic Blog

I have an old, sentimental newspaper-article-cut claiming “pessimistic hi-tech employees are more productive than their optimistic peers” hanging on my office wall.

In this context, last summer I wrote, coined and trademarked the Pessimistic Developer Paradigm.

Early this week I have interviewed a very interesting dude* who saw this old article hanging on my office and introduced this amazing poem by Robert Graves which I must share in this pessimistic context…

In Broken Images (by Robert Graves)

He is quick, thinking in clear images;
I am slow, thinking in broken images.

He becomes dull, trusting to his clear images;
I become sharp, mistrusting my broken images.

Trusting his images, he assumes their relevance;
Mistrusting my images, I question their relevance.

Assuming their relevance, he assumes the fact;
Questioning their relevance, I question their fact.

When the fact fails him, he questions his senses;
when the fact fails me, I approve my senses.

He continues quick and dull in his clear images;
I continue slow and sharp in my broken images.

He in a new confusion of his understanding;
I in a new understanding of my confusion.

* Thanks Tomer and Good Luck!

The Pareto principle (a.k.a. the 80-20 rule, the law of the vital few and the principle of factor sparsity) states that, for many events, 80% of the effects comes from 20% of the causes. (e.g. Your wife might claim that you wear 20% of your closet clothes about 80% of the time… ;-)

I will argue that pareto principle conceals one of the most important princples in software (and not only in software) management - Don’t try to do more. Just do more of the right things!

exempli gratia

* Don’t invest too your time in dark software corners since the same principle will catch you with investing 80% of your force with only 20% value (e.g. What will happen if someone disconnect the database network cable 1 minute before DST transition… etc.)

* Don’t over design since you will bump into the 80% investment for only 20% value again – Don’t drill the holes for air-condition system before you have one, since you might find yourself a bunch of holes in the wall…

* While planning, always ask yourself if you can do more for less and try to find that thin-gray-line that cross the 21% effort for the 81% value* - try to identify how to invest minimal effort (~20%) to create enough (~80%) business value.

* In performance tuning you want to find the silver bullet that with minimal effort (let’s say 20%) solve 80% of your issues (a.k.a. low hanging fruits)

* Workforce wise - Jack Welch’s vitality model has been described as a “20-70-10″ system. The “top 20″ percent of the workforce is most productive, and 70% (the “vital 70″) work adequately. The other 10% (”bottom 10″) are non-producers and should be fired. Rank-and-yank ideologues credit Welch’s rank-and-yank system with a 28-fold increase in earnings (and a 5-fold increase in revenue) at GE between 1981 and 2001 - Obviously, this is a tremendously competitive model of organization and all criticisms of both the morality and (in)effectiveness of such a Dog Eat Dog method of social cohesion apply but as a manager you must take this in mind since reality and statistics (law of large numbers) do show that the “top 20″ percent of the workforce is most productive and is doing 80% of the work…

I would even dare claiming that, perfectionism is a strong indication for weak leadership!

——————————————–
* Note: I was told that everyone knows this principle but the question is how to do it… so my tip (and I promise to post more around this dilemma) is to handle this with-in the scoping of the feature or module; efficient scoping should get very fast to ROI (look for the items with low ROI) and risk analysis (look for the items in high risk and try to understand where the risk come from) and soon after the tradeoff discussion which is the perfect time to take the hard “cutting” decisions and for doing this you must have someone in the room with deep customer understanding; e.g. In most systems it is very “easy” to cut enterprise-readiness features to simplify development (I18N, Security, Upgrade, Scalability, High Availability, Distribution, Monitoring etc.) and many of those features can be added later if needed with no real overhead (warning: you must know what you are doing to make it work so don’t try this at home if you don’t have professionals with you);