Learning disability

While watching the world cup cricket match between South Africa and West Indies, I checked the history of cricket in West Indies. I was impressed with the side’s virtual invincibility in the 70’s and 80’s. There were so many greats and top achievers and at a point of time many records were being held by their team. Even more impressive was the fact that it was not a single nation’s team but a federation of cricket clubs spread across 12 different countries. Going by the performance in the last decade or so I could hardly believe that they fielded the greatest cricket team.

I inferred that the team suffered a learning disability when they were at the height of their power. Peter M Senge in his book “The Fifth Discipline” lists out the learning disabilities a person or organization can go through. The one example that comes very closely  to explain the case of West Indies’ decline is “The Parable of the boiling frog”. A frog will jump out of kettle if you try to drop it inside boiling water, but if the frog was already there inside the kettle and slowly the temperature is raised; chances are very high that the frog doesn’t realize until it is too hot and dies in the boiling water.

Humans evolved to react to sudden threats (fight or flight) and not to slow changing events, the West Indies team members would have thought that they are being too successful in cricket that they will be able to face any team any day and win. What they did not look forward was to groom the next generation of greats and ignored the responsibility to promote new members.Combine this disability with the economic issues and weird logistics issue in the federation of clubs across 12 countries, the cricket team board never got up from deep trenches.

Organizations and individuals can also get stuck in a similar situation where they are on a performance plateau but don’t really see up what is in store for them. One of the factors which holds back anyone from learning or moving on, is to leave the comfort zone and venture into cold waters. The other significant factor is the learning horizon, if we don’t get an immediate feedback on what we do; we generally tend not to pursue that activity. Constant learning is a continuous and long term investment which can’t be very easily observed or quantified. Great flourishing civilizations have disappeared due to outdated weaponry and fight methods. Companies and individuals will have no other way to stay up than to keep on learning.

Firemen theory

Mark Glouston in his book “Just listen” says

Every one has an invisble tag around their neck which says Make me feel that I am an important person

That quote made me recollect my experience at the work place and ended up coming with a theory to explain the behavior which I named as firemen theory. I classify firemen into two types based on their reaction to a scenario.

SCENARIO: A fireman is on duty in a shopping mall and notices a dustbin on fire….

TYPE A: He notices the fire from the bin, swiftly acts on putting the fire out. Not only he does that but investigates for the root cause by talking to people nearby about the incident and educating the people around what could have caused the fire. This act helps in putting the fire out easily and makes sure people are educated about it.

TYPE B: He notices the fire from the bin; runs around crying FIRE FIRE FIRE. People notice him and try to locate where the fire is and a mix of panic and curiosity sets in. In the meanwhile he announces that people need not bother as he is well trained to handle the situation and directs two civilians nearby to fetch water. The fire grows in size and looks like it will spread its wings to nearby locations. After a tough attempt the fireman manages to put the fire out along with some of the civilians and ends up getting standing ovation and countless compliments.

The regular workplace is no different, people like to be recognized and that makes them feel happy. Heroic efforts are well rewarded & recognized and hence some people resort to seek attention. As it takes a good deal of time to understand the system and the good effects of living in a symbiotic relationship with the environment; it is so easy for a type A person to become type B as the personal gain and the sense of well being is granted, but it comes at the expense of more work to everyone and loss to the overall system.

Every workplace has to nurture the symbiotic culture and educate people about the delayed feedback about the overall gains in such a setting. It is very evident from football games where every team member’s move counts and all it takes is one selfish person to spoil the goal. Sadly people have a narrow learning horizon that many don’t see the long term effects about immediate actions.

How to bring the mindset of type A firemen into everyone? My observation so far has been that it is a slow process which involves a lot of patient type A people educating every one around non intrusively and show immense perseverance to drive the culture up. They should also tackle type B people which will be an art in itself. We should also be very cautious because all it takes is one selfish person to spoil the entire effort of a well knit team.

Let us strive to make our workplace environment healthy.

Whistle blowers

Before you begin reading  you must watch the short 45 second clip.

This video towards the end shows a hesitant thief mustering the courage to pick a pocket. On hearing the kid snap his finger he is disturbed and out of fear drops his idea and walks away, hence a crime has been prevented from happening. It was a coincidence that the thief thought that someone else was looking at him.

I loosely compare this to the Continuous Integration server where the build turns RED for the standards we set. Most of the bad parts while coding goes in inadvertently during the rush hour of check-ins. I usually observe the rush hour to be close to the end of the day and the next day, the refactoring is put into back burner which grows into tech debts and makes you repay at a later stage. Along with the other devs in the team we set some simple rules in the CI to fail the build. The rules are

  • More than 12 lines in a method
  • NPath complexity more than 4 in a method
  • More than 4 lines of code copy pasted across any file

An intentional check in to avoid these rules and send in a bad code could not be prevented; but someone in a hurry or tired individual checking in gets a hint that code could be bad. A quick introspection will lead to corrective action and things could be addressed then and there instead of carrying a tech debt. The rules above are neither comprehensive nor does this guarantee awesome code, but it has caught me and others red handed when looking for quick gains. We are exploring more options to configure the CI to help us keep on our toes.

The elephant and the pot

Whenever I met someone new and talked about business analysis, requirement gatherings or happy customer; I used to narrate the following story from Tales of Tenali Raman which I read in my school days. The story has many variations but the crux is the same. It is about the king who promises to Tenali Raman that he can keep any one in this world happy as he has the powers and resources to achieve that. Tenali Raman challenges that it is impossible and brings a kid to the palace.

The King sits beside the kid and tells him that he will get him anything to keep him happy. The kid immediately asks for an elephant and gets it. He goes on a joy ride on the elephant around the town along with the King. They stop when the kid gets excited on seeing a pottery ware house and asks the King to get a fancy looking pot for himself. The King obliges and orders for a pot. Now the kid asks the elephant to get into the pot and the pot breaks. The kid lets out a loud wail that the pot is broken. The King to keep up his promise, orders one more pot and the same thing happens. It keeps on happening until all the pots are broken and the kid continues to cry. Having watched all this, the kid’s mom rushes in with a small toy elephant and convinces the kid that the toy is so good that it fits into her basket and they can take it home. The kid gets convinced and leaves for home happily with his mom leaving the embarrassed King behind.

Why I narrate this story is, we are right now moving our days through information overload and the idea of the whole system never gets painted in our mind. We always tend to think problems to be linear and little do we give a thought about how small actions can have long term effects. In the above story the King never asked the intentions of the kid when he asked for a pot after getting the elephant, had the king known that before he could have talked the kid out of buying the pot by explaining before the kid lost his cool. Similar situations happen in day to day work especially when requirements are collected iteratively; but the situations are not so easily visible to our eyes like the elephant & the pot story and end up with rework because of trying to achieve something as a result of completing it by parts.

We need to acknowledge that there exists a system which is not linear and the whole system is much more than just the simple sum of the parts. Also wish to introduce a term from the book Patterns of Software, by Richard P Gabriel

Organic Order – the kind of order that is achieved when there is a perfect balance between the needs of the parts and needs of the whole.

Don’t make me think

Hamcrest matchers provided a good way of expressing the assertion in the tests. Combined with the method name and the way you write your assertion it becomes expressive. Bringing it into the middle of development phase when all the other tests have been written using regular assertions was not so desired. So restricted that to starting something from scratch.

Java programmers would have gone through the boring ‘for loop’ and collections manipulations for any applications. Both in the tests and production code it was almost necessary to transform view objects (a necessary evil) to and from models or go through a list and collect the just the names etc. CollectionUtils from apache provided a good way to work through the mundane for loops and do most of that stuff. CollectionUtils.collect(list, new Transformer() {<transformer code>}),  CollectionUtils.select(list, new Predicate() {<predicate code>}) did good help to reduce remove the for loops out of sight.

I then moved on to Groovy which is when I got smitten by the ease at which we can use collections. All we need to do was to call .each or .collect on the collection and put the respective code in the closure. Having tasted this going through the CollectionUtils in java was suddenly looking like an eye sore on the code. I discussed with another developer (incidentally his name is the same as mine) about the problem. He immediately jumped in and said that he had used LambdaJ and it uses Hamcrest matchers. We immediately explored through the code and started replacing Collections.sort to LambdaJ alternative. The code

Collections.sort(personList,new Comparator() {

//comparator code

})

changed to Lambda.sort(personList, on(Person.class).getAge())

Once we tasted success with the first replacement, we went scouting through the code for “for loops & CollectionUtils” and ended up having interesting looking self explanatory code like

Lambda.filter(having(on(Student.class).getAge()) ,is(greaterThan(20)),studentsList)

On doing the static import, the Lambda prefix also disappears. The power of Hamcrest matchers and LambdaJ’s thoughtfully made collection utilities help in making Java code more easy to read. It also has brought closure support to Java (Limited somewhat due to Java’s nature) which looks promising but I am yet to explore its full potential.

As more and more people are getting their hands on other programming languages and switching back to Java due to client requirements are making Java more and more readable and easy to use with these kind of APIs. You can spend more time thinking about the functionality, design rather than getting bored with boilerplate stuff. What else is in store from polyglot programmers?