Monthly Archives: March 2011

Peer pressure vs beer pressure

Much has been written about the effects of peer pressure – both beneficial and harmful. The nadir of peer pressure was of course depicted by Chatur (Silencer) in the movie “3 Idiots” – a case of constant comparison and competition. Unfortunately, not enough research has been conducted on beer pressure – the pressure felt subsequent to beer intake. This has caused a large leaking hole in our body of knowledge on these two types of pressure, leaving youth of the world clueless about which pressure to adopt.Let us compare these two so that we may choose between them as informed adults. I strongly feel beer pressure is the right pressure, and my fair and unbiased arguments will hopefully prove the same.The Big Fight

1. Peer pressure leads to fear, beer pressure leads to cheer
Constant comparison causes anxiety and fear of various kinds to build up inside individuals. This anxiety can affect the quality of life and work of even the most saintly person. On the other hand, beer pressure results in instant and all-forgiving, all-forgetting cheer that warms up the soul and fires up the mind.2. Peer pressure causes bottling up, beer pressure results from un-bottling
Those who choose peer pressure are always looking over their shoulder to look at who is drawing close, as if the race can have only one winner. Bottled emotions cause scarred lives and incomplete human beings. The very first act in beer pressure, on the other hand, is un-bottling, a magnificent celebration of the release of human potential.

3. Peer pressure causes loneliness, beer pressure causes belonging
When you choose peer pressure, you are alone – every friend is a peer is an enemy. When you undergo beer pressure, you know you have a purpose, a mission, and you belong to a worldwide movement called “No Bottle Left Unopened” – all in it together.

4. Peer pressure is a complex path, beer pressure is a simple path
Complex is the person who cannot get away from comparison. Peer pressure takes you down a complicated path built out of competition and deceit, slyness and jealousy, envy and hatred. Beer pressure generally creates for you a straight and simple path, generally to the nearest washroom.

5. Peer pressure makes you mad, beer pressure makes you glad
Peer pressure = can’t get badder
Beer pressure = gladder in the bladder
Mathematical justice for poetic art.

6. Peer pressure implies hierarchy, beer pressure means equality
Comparison inevitably assumes that there is an underlying hierarchy of superiority and inferiority, of humans stacked on an unequal ladder. Beer pressure assumes nothing and believes in fundamental equality of humankind. You build an equal world glass by glass.

7. Peer pressure is measured in numbers, beer pressure is measured in decibels
Peer pressure is based on comparison of numbers. Exam scores, weights lifted, goals scored. Numbers don’t have personality. Numbers are drab. Numbers are black and white. Decibels, on the other hand, are colorful. Beer pressure is measured in decibels. Decibels come in flamboyant red and flaming orange and fantastic indigo and fabulous turquoise and f… perhaps we should stop here.

8. Peer pressure kills, beer pressure fills
No explanation required.

9. Peer pressure is free, beer pressure costs money
True. But free things are not necessarily good things. And beer pressure does invariably cause free speech, so there.

10. Peer pressure is driven by expectation, beer pressure is driven by desire
You truly shine when the person inside you can come out and shine. Peer pressure hides your true self, since you act as peers cause you to act. Your life is driven by others, from outside. When you enjoy beer pressure, your life is driven by you, from inside. That is when you truly shine.

11. Peer pressure means a small view of life, beer pressure encompasses the universe
Restricting our world view to our immediate others – our peers – is such a limited view of this wonderful world we live in. Break those barriers. Adopt beer pressure and you will feel at one with the universe – vasudeva kutumbakkan – which may someday lead to world peace. It is our duty to try.

12. Peer pressure elevates performance, beer pressure elevates
There is an argument that peer pressure can also be healthy competition while beer pressure is unhealthy consumption. I agree that peer pressure can elevate performance under the right laboratory conditions. However, my learned friends forget that beer pressure elevates – period. Doesn’t matter what – performance, life, friends, family, memory, mood, work – beer pressure elevates all. Indeed, there are frequent instances of elevation leading further to levitation.

And the winner is…

Evaluating with a fair mind the dozen arguments presented above, it is crystal-clear that beer pressure wins over peer pressure. Peer pressure needs to be banned and banished, and a movement has to begin for beer pressure to be made mandatory.

Some readers will oppose this conclusion even after agreeing with above arguments – submitting unconsciously to the very peer pressure they need to oppose. However, please understand the simple significance of this matter. The future of world history depends on what we do today. Let us build a culture that wipes out peer pressure in favor of beer pressure.

Relevance to Software and IT Industry

Leaders and managers in software companies especially, have to build maturity and responsibility in their software engineering teams with young people who have just been liberated from years of peer pressure. This is a tremendous challenge not to be taken lightly even slightly. There is no better path to this goal than beer pressure. The way to build team spirit is to do it with spirit.

I hope all leaders recognize the dangers of peer pressure, and promise not to use peer pressure to create differences among people in pursuit of “better performance”. Instead, use beer pressure to bind people together. Performance is science, togetherness is magic.

 

Peer pressure is for losers. Peer pressure is un-cool. Cool is the person who is incomparable, for s/he is peerless. Be yourself.

Down with peer pressure. Hail beer pressure.
Cheers 😉

Author – Chinmoy Panda

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Software Testers: Who is your boss?

I was spending some time with a software test engineer (Software tester) recently and have a simple realization to share.

“How come this runs so slow?”
“Oh it runs just fine, just some problems only in IE browser”
“Why?”
“Probably IE’s Javascript doesn’t run so well”
“Yes but soooo slow?!?”
“Yes… but my Lead has seen it and knows about it”
“Which means it doesn’t matter?”
“Well not that… client has also agreed to Chrome-only support”
“The site will support only Chrome?”
“Yes, we described the problem and got client to agree to it”
“Do you have it in writing?”
“Yes”
“Very good. But why is this the case in first place?”
Developers told me the 3rd-party component doesn’t run on IE.” (look on face: how does it matter since client has agreed anyway)
“You mean a best-selling web UI component library doesn’t run well on IE???”
“Yes that’s what developers told me”

After some pushing and research, it finally turned out that developers had to use another method of data access and voila! – everything ran smooth on all browsers.

No doubt, the incident above and its subsequent resolution display several best practices. Get acceptance criteria in writing. Make sure client understands limitations. Don’t trust explanations! Be hard-nosed. Use common sense (how can a best-selling web UI library possibly not function well on IE!). Don’t let your personal love override the obvious (Chrome is great but that doesn’t mean you can force users to switch).

An aspect I would like to focus on is: to whom should the software tester be responsible? Project Manager? Team? CEO? Entity/person who is paying for work?

In the course of project teams and organization and “reporting structure” and salary and revenue and a zillion other things, we forget what is obvious. In reality, the Lead/Manager doesn’t matter. The developers do not matter. The CEO doesn’t matter. The client doesn’t matter! They are all illusion, maya.

The only person who matters, the only person who finally decides, is the user. A software tester is responsible towards only the system being tested, and users of that system.

In the short run, you can get away by keeping your Lead/Manager happy. You can get away by accepting superficial wave-of-hand explanations from web application developers. You can get away by getting clients to agree to something illogical. You can get away by using bureaucracy to cover your behind – “I have it in writing”.

You can get away because the short run is imperfect. The short run can hide. But the long run is all about the right thing. The good thing. The correct thing. Quality. Truth. Details. Finesse. Care. The long run exposes everything.

The right thing here is to find and fix the problem, or find a workaround if it cannot be fixed.

If you do not, all might be well at the surface. But when the user rejects it in the marketplace, everyone loses. And why? Because we ignored her when we should have paid attention. We got confused by irrelevant intermediaries (colleagues, lead, client, CEO) and forgot who the software is being built for.

In the example above, the user is taken for granted. The user is actually expected to tolerate slowness, or switch her browser if she wants to enjoy our system. The IE user votes No and many users are IE-only. Yikes, that pinched!

As a software QA tester (whether for a web site or web application or desktop system or mobile app or server software and so on), you are the user’s voice and warrior. Don’t accept reasons. Make your point. File issues where you see issues. Revolt till someone notices. Help in getting the right thing done. Ride alone if you have to, but ride the right path.

Honestly, you are not alone in getting deceived by quick things. It is the same thing in business. Business gets confused by targets and profits and “customer satisfaction metrics”, because those are the quick and measurable things, although they are not what business is about. Business is about doing the right thing for people, not only the legally right thing.

Software testing is about doing the right thing for users, not only the officially right thing.

Thanks!

Author – Chinmoy Panda

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Group Code Review

Group Code Review :

As part of CodeCAT (an area under the umbrella initiative we have at Mindfire called Catalyst – an initiative to improve competency of every person involved in software development) we have been doing code reviews regularly. After every review we post the findings in GPS (our company’s intranet) so that everyone else in the company can go through the review and get to learn from that.

In the beginning the enthusiasm was there but over time what we observed is that mostly people do not go through other’s code reviews. So the intent of spreading the knowledge of one code review (which is typically a one to one session) to many others was not being met. I started taking awareness sessions for all people in batches – things improved after that but not as much as we would have loved it to be. Something had to be done !!

Since we were clear on two basics things – one is the quality of code review being done was good and second was we were sure what we needed to improve,i.e spreading the knowledge of one review with others. This awareness of our strength and area of improvement helped us in coming up with an effective solution. We decided to start “Group Code Review” – call 5-10 developers to a room and have 1-2 code reviewers, pick 1-2 projects randomly and start doing a code review there itself. The intent was to spread knowledge and sensitize people not to repeat silly mistakes.

We anticipated that people might object to this way of review so what we did is we started collecting opinion/views from the codeCAT team members(of 25 persons). We had a lot of discussions on the pros and cons of having something like this – people might like it or might not.

After a lot of discussions we finally agreed that since our primary intent is to spread knowledge among more people and at the same time ensure that reviewees take up code review comments seriously and work on improving their code quality – what we decided to do is have the first round of group code reviews done team wise and by the team lead (the team lead had the flexibility to call other reviewers too). So instead of the earlier plan where we thought to call randomly 10 people working in one technology (but in different teams) and have 1-2 codeCATs assigned who in the meeting itself pick out few people for review, we called people working in 1 team for review. Since the concept was new to start with – we realized the earlier approach will not work because people might not feel comfortable. So we called 7-8 people working in 1 team to a room and got the code of 1-2 persons reviewed by the team lead (if he happens to be a CodeCAT – in the first phase we called teams whose team leads were CodeCATs). The review session was used as a forum to not only identify mistakes done by developers but also was used as an interactive discussion forum where people got a chance to ask questions and understand why something will not work and what changes need to be done to make it work.

So far the feedback from the team members, who participated in the reviews , has been positive and people seem to be liking it. Ofcourse the next round of reviews will be a little challenging when we pick groups of 8-9 people randomly and assign a reviewer who they have not worked with. I will keep you posted on what our findings are after we do that plus things that should be taken care of to make group review more successful.

Author – Atma Prakash Ojha

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •