let there be bugs...

Programmers! Always in a battle against infinite possibilities and limited lines of code, limited time, limited budget and limited patience! And on top of them all limited brain.

We start development. We think we can do it all. We think we can code a perfect program. Huh! What's the big deal.

We start testing. We think those bugs are fixable. Ah! How silly. We will fix them rightaway. Tiny bugs - here we come.

We start integration testing. We think, other programmer's code sucks. We think - she must change her code - dim wit! But then compassion takes over and we believe in hope. We change our own code and move on. Don't look back - no regrets.

We start system testing. We think, we need a break. But then we change the code, add new lines to it, but we know we are slowly losing it to anonymity.

Users start testing. We wish we could go on a long vacation which would never end. Can do no more. We have already run the scripts 107 times. Someone take it away from us. We don't do anything anymore. Someone pushes us - do it! do it! do it!

Code goes live - and we say - Never again. It's ok to be imperfect. Let's just evolve. Don't be perfect. Let there be bugs.

team meat...

Believe me, this is from a real life incident. There exists a cabal of very high profile managers, drawing millions of vanilla rupees with chocolate toppings of perks every year, who when want to send a meeting request to their team to discuss a burning project show stopper send a note something like this:

Ironical as it may seem - the gathering actually turns out to be nowhere near to a team meeting. It actually justifies the words which appeared in its coming - TEAM MEAT. There is no agenda, there are no meet me details or a room - a perfect aspirant of the book "101 ways of how not to set up meetings".

Here is how such meeting's life cylce goes - first attendee will ask second attendee about the meeting details, surprised that they both don't know - they will go to third attendee to see if she knew. Until all attendees are covered (except the geeky ones, who like to think that it is their prerogative not to attend any team meeting) this process continues and become a meeting unto itself to discuss why the meeting details were not sent. When nothing comes out of this discussion - everyone decides to go for a short break to get a cup of coffee to ward this interim meeting's after effects.

Five minutes before the actual meat (meeting) - everyone's looking at each other's face to find where the meeting is. And then suddenly - like the 'Big Brother' reality show, an akaashvaani (annoucement) happens 'Big Brother ne aap sabhi ko so-and-so room mein ikattha hone ko kaha hai' (Big Brother wants all of you to gather in so-and-so room). There is tension of a vote-out in everybody's face - 'aaj kiska watt lagega' (who gets the beating today). Everyone's making their excuses in their minds, everyone's thinking of what to say in the meeting without any agenda, where anything can be expected.

After gathering his flock in the room and making them wait for a few minutes - the saddist, the voyeurist Big Brother appears in his incorrigible unmistakable appearance. In a two hour call - first 20 minutes go in deciding what the agenda should be. Next 20 minutes go in deciding who will speak what and how much and about what. And also, who will not be allowed to speak at all. Then next 20 minutes go in finding out and targetting a bakra (scapegoat) who can silently take up all the insult and aspersions which are coming his or her way.

After one hour - some sincere guy loses his or her patience and says something which nobody likes and next 20 minutes go in settling the dirt down. Last 40 minutes are the most crucial ones. Because this is the time when the Big Brother asks the most difficult question - 'Who is preparing the MoM'? At this time - some people wish the earth tore in two parts beneath their feet and swallowed them, and some wish a meteor fall on Big Brother's dim head. Then some poor fresher has to open her notepad and start pretending that she will do it (but in her mind she is thinking what the heck did we discuss here.)

Now the last 20 minutes - everyone looks at the sincere guy and try to make some sense out of his subject matter expertise displayed very vaguely by his poor communication skills. Big Brother with his big mouth says 'great analysis Sincere Guy' and then blurts out actions on each of the team members as if giving a sermon on the mount and the poor girl jotting down as if writing another new testament.

Even after so much of blamebrainstorming - 10 minutes are left out of alloted 2 hours for the meeting. Then Big Brother takes a soft stand and asks the question which everyone was waiting to hear - is there any other issue? - because this question marks the coming of end and people who were holding their bladders for last two hours can go out and spill their frustration on to the toilet, thinking of how they would want to beat the sh** out of You-Know-Who.

Alas! Life is unfair. Skills are so unfairly scattered. When will I get to become the Big Brother!

quick and dirty...

I am currently a small drop of tasteless technical skill in the large ocean of strategic migrations. Among big waves of business process analysts, programme managers, solution architects, implementation managers and project managers, I exist as a tiny insignificant and expendable ripple that’s called a developer. By a random divine decree, which some people call fate and others coincidence, this tiny wave got a chance to whirl along with big waves and behold the glory with which they exist in this corporate valley.

Data cleansing is an important part of any migration exercise. It’s like letting go of the old and useless, and adapting to the new and useful. Migrating from an old technology to a new technology, from an old business model to a new business model always requires data cleansing to be performed on the source data.

Some of the data currently under the scope of migration needs to be migrated ASAP because it has intricate dependencies with timelines and budget. To clean and data-migrate this piece, a poor developer (not me) had come up with a ‘quick and dirty’ approach. As soon as projector projected the slide on the wall with ‘QUICK & DIRTY’ written on it, there was a burst of laughter among the members of the elite solution club. Visibly, everyone could comprehend the hidden vulgarity. For those of you who are naïve and unaware of the latent dilettante (which I hope will be very few) when someone says ‘quick & dirty’ in an American accent, it feels more like coming directly from the Sunny Leone’s or Sativa Rose’s mouth from an X rated movie. (WARNING: Please be careful if you get curious and start google-ing these names in your office systems.)

Dirty minds, if you ask me. Or may be naive big-shots who don't have knowledge of programming terms. Because according to Wikipedia, “Quick-and-dirty is a term used in reference to anything that is an easy way to implement a kludge. Its usage is popular among programmers, who use it to describe a crude solution or programming implementation that is imperfect, inelegant, or otherwise inadequate, but which solves or masks the problem at hand, and is generally faster and easier to put in place than a proper solution.”

Well, the poor person who made the slide had other intentions, in line with the wikipedia definitions. Intentions were to “quickly” set up the data even if that meant data was “not so clean” or “dirty”. Well, obviously he was misunderstood by the elite cabal. Idea was simple – given the data has no use for future processing, is static and drives no revenues or reports and needs to be set up one-off just for the reference in the database, there is no point spending time and money on cleaning the data to give it a correct & meaningful shape. After intermittent bursts of laughters and grins among all big waves, the plan is (still under review) to keep it quick and dirty, until ofcourse the management cabal comes up with some "calm and clean" ideas!