Wednesday, May 21, 2014

If my stupidity helps the team/product...then be it...

I have no false assumptions or feeling that I am the best software developer that every lived on this planet. I can write code in languages (java, javascript, some test code in ruby...) and they are good enough in quality. The good-enough is a relative and debatable term. For me it is good-enough if it follows design which scales (for performance, future changes, adaptable, etc) and follows the customer's requirement. 
The reason why I am making this self-declaration is because of the kind of language senior colleague continue to use in the team. He is a top performer and he is brilliant and I have learned lot to things during my course of working with him. Yet his way of speaking is not at all good. He is never reprimanded by my manager as without him, the product can't deliver fast & furious (or at least that is what the believe is for the management). All my manager can say is "Please improve on it, and here is the best rating you can have". I will talk about this little more later.
Coming to the part where I did some stupidity which actually helped the product/team. We had a small training (which most of the participant didn't take seriously) which deeply talked about using different libraries to test the product. TDD (Test Driven Development) even though exists for long, it is hard for lot of developers to use it every day. The training had a good section on TDD.  Coming back from the training I personally realized our functionality has 'no' safety net. There are just not enough test cases which need to protect our code changes. So I began the challenge to take our code coverage to 75% if not 100%. That was the base line challenge because there are everyday change/addition to specific code base + lot of different teams are working on the same code base. To save what we have already done, this was the need of the hour. Due to strict timelines and of course the 'stupidity' I did, the assert in all test cases are comparing two strings. While the expected string is stored in test case project as a file, the other string is generated. The ideal approach would have to parse the generated string and check whether the expected values exists or not, without bothering about the other content. I knew at that point of time the approach taken is wrong and I was stubborn about it at the beginning in Scrum. I have wasted a good opportunity to write good safety net for a reason. 
And the reason is simple: Everyone in the team was lazy and that includes everyone (me, the top performer, the low performers, everyone...) in writing test cases. Just because the code runs on server and it is difficult to write test cases, every one avoided it. The training really brought an easy to use mechanism and I now have done the initial work. Had I opted for parsing the generated string and doing what is required, it would still have been the same state in the team. Getting people to write test cases, maintaining test cases is one of the hardest thing to do. People don't really understand the importance and believe that manual testing at the end of every cycle of shipment can deliver real quality. From then on, things started to break as soon someone started writing new code, new functionality. Now the build breaks because test cases aren't passing through. If you comment out the test case (calling it 'idiotically-written-code' or 'stupid code' - terms used by 'Mr.Top Performer'), the coverage matrix drops below 75%. Developer has no escape, but to write it, fix it... And then the original idea of parsing of string and validating the existing content started to knock on everyone's head. 

Few Debatable points over the whole conversation:
1) I could have written it the right way and code coverage would have gone down; we could still reprimanded the developer. 
    This approach might have been the right way to do it, but then developers are writing test cases just to get the code coverage up and not really to cover all scenarios which will save the code from future changes. 

2) Lead by example by doing the thing write and then reprimand the developer who doesn't follow.
    The monster company I am in, code coverage hasn't been ever the main cause for concern. Quality is just not the habit. Yes I agree, I am generalizing every developer under the sun here (but remember I am pointing that same finger towards me first), the new bunch could have proven me wrong and hence I am also calling my approach stupidity to begin with. 

***

While this blog talks about the quality aspect of the software development, I don't think I would do it again. I try to write as best as possible each time and hope people lead from there. Further on, I mentioned I would mention something more about how things are governed. I happen to be aggressive when doing development and indeed went over-board (and apologies later) to my colleague for being aggressive. Still I end up getting the best rating company has to offer last year. The behavior aspect of a colleague isn't considered if you deliver the best. Sad as it may be, this is what is it. The product is greater than all emotional and mental state. Customer doesn't pay for how happy we are but how good the product works. Build it under stress or under joyful state is one choice. I choose to stay as joyful as possible and whenever I find my mind getting stretched, use my blog as a pensive to cast the thought away.

Sunday, April 20, 2014

Emotions have no place in professional coding...

For the past few months I have joined different team. The effort comes form the management to increase pace of a certain product our company is building. Of course I can on my blog criticize my company on waking up almost two years later on building this product, but again that will be really against what I have learned recently.

The idea of working with a different team was initially scary. Mainly because after having become dinosaurs in building UI on a specific platform, switching to a different platform, learning new technology along with different programming languages was freaking me initially. Yet there are times challenges are right in front of me and all I have to do is stand-up. And here is the need to not think 'emotionally'. Questioning oneself with all the doubts in world - "Whether I would be able to learn this or that?" - "What if I make a fool of myself?" - "What about if I code really bad in the new languages I would learn?" -- all of this were the exact emotions bubbling to the surface. How did I overcome this, by reminding how I got selected in the first place to this company seven years back. I used to work in completely different platform (AS400/Mainframes) with a very very tiny component which was in Java. The java part was just maintenance with no new development but scope for lot of improvements. Like any service company, innovation wasn't the need of the hour but keeping customer happy was (as always). Yet as a young kid with time on his side, ventured into the unknown creating something unique (small but unique). The customer liked it and I learned Java to some extend (still learning...) So what really happened here...I was not emotional, I was fearless, I was thinking like a college kid in mood to do things, giving it a try without the fear of failure or success. 

Seven years down the line I did something same. realizing I have become dinosaur of this Java technology, I liked the idea of doing it all over again. 

To start with, I saw an example of someone really senior in the team I joined keeping his emotions in check. What the management decides in future, whether we will take over this product or will continue to contribute is debatable point, but this senior guy welcome us with open mind. His idea was simple, share the knowledge and let the product grown, right now that is the agenda and all the future thing are not. Had he gone over the range of emotions and arguments attached to that, "why should we give away our hard work?", "Is the senior management questioning our capabilities and want outside parties to work on it?", "We asked for the same thing two years back; why they waking up now?"; we (the whole team) wouldn't have reached this far. 

During the whole process of working in new team there was a different activity of people management going around. For me it is troublesome and something which I can't talk-out-loud. No, it is not about the last post on my blog, but yes everything to do with my company. The only part of it I can say out here in this public forum that it has impacted me so deeply that I have lost respect of the my company's (in India) management completely. I am not involved with this management on the day today basis and are not part of my development management group. The whole set of emotions which I am feeling (and will keep on feeling) are something which has impacted me professionally. It did cloud my judgement on one occasion in making what would be the right choice for the product. And from that I have learned, emotions are the devil which will stop you in doing what is needed and waste time, energy and lot of other resources pondering over it in-turn resulting in bad choices. 

There are two more instances for which I am proud that I prevailed over my reactive-emotions. First was when my own team poked me with useless questions about whether I am following their progress while working in different team and making remarks which had nothing to do with my questions. All I did was question which will make sure our product is delivered with the features we are promising. Very happy to say, I adapted quickly, questioned the right guy and aligned it quickly. Had I ponder over the emotions the team managed to generate, I might have been late in our promise. 

The second of situation is still in progress, it is the reason why I had started the blog in the first place. We all love the code we write; we all hate when someone points out that there is serious (or not so serious) bug in our code. But does it really matter whether hating or loving code will make our product better. There are product owners who are supposed to envision how the product evolve, there are senior architect (very very senior) who overlook the information flowing in to respective team architects for concept/design and finally there are developers who get the code rolling. Because of this long chain of information sharing, smaller things are bound to be overlooked. Some where someone will question about these smaller things and it is possible we reach state of unknown. So as a developer with few months of experience (of course the new place has new technology) questioned seasoned campaigner who in my opinion has the most brightest of ideas when implementing solutions. Why I questioned it? Because I checked the first set of emotions of 'what will he think?' or 'Am I making a rookie mistake'.... Then post his reply, which I felt strange, I checked my emotion again of 'feeling-strange'. I questioned again about the need of creating something which the framework already provides. If something isn't working by the framework's logic itself, then something might have gone wrong in the way our logic works. Or we just might have discovered bug in the framework's logic. I didn't let my emotion cloud my statement. I explained what I understood of how-to-use-the-framework and let the team's architect to make the call. If similar opportunity comes in future & I have to make a call this instance will assist me and I will have a baseline as to how others thought about the different ideas pertaining to this product. 

Lastly, how would my reaction be if the team's architect didn't like my approach and want to follow the existing behavior? I should debate without letting emotions getting better of me. And in the end let go irrespective of the outcome. Some what during the process of writing this blog, I have let it go. I learned something, I did something for making product better. I still love the code I wrote and I am still trying to keep 'emotions' & 'professional-work' in two separate chambers of my head :) 

Tuesday, March 18, 2014

Enough is Enough...

Bruce Wills says in Die Hard 4.0 -- "Why I am doing this, because no one else will. If anyone else can do it, I would be happy to give it up". This is the reason why I am making a documented effort. 

For the first time in my seven years of working in my company, I have to say, "I had enough of it". Someone should stand up and say to our MD, this is just making 'my company' is a good enough place to work, but doesn't have the best of environment/management. The number of ground level problems have been so many and the resolution so few. Why common sense can't prevail in so many of these scenarios? Why every time a developer effort has to be spent to solve management issue? Why at the end of every question raise, I am left with the feeling, "why in the hell I raise it in the first place". We are sooner or later gonna turn into a Indian Govt. organization where Dinosaurs are ruling, who have no imagination or anything. Extinction isn't far away my friend.

Few things I would like to say before I begin about this extreme desire to vent my frustration. 
  • People who know me will definitely understand the company I work in. Please again use your common sense to talk about this or comment about it. 
  • This is not about the work we do. I am extremely happy for the opportunities I am getting and my manager has over the years have acknowledge it.
  • This is an 'Emotion' response. If someone is here to bind logic, please use your own common sense to judge for all these problems because if you don't have that, ideally you are the same group, against whom I am sharing this frustration.
  • I can't at any cost take name of my company, because it can than be taken up as propaganda. I have been in this company for seven years and will always propose my company to other friends, so I have no hidden agenda here. 
  • The reason why this has to be documented, because until it is in my system, I will remain angry about the whole 'thing'. And this 'anger' or at times sense of desperation will cloud my judgement to appreciate the good things which come along. 
  • My fellow colleagues have reached that plastic state where they are living with these problems. They don't want to fix the broken system; The don't want to give feedback; They can complain as much in-person, but can't grow enough balls to send an e-mail to management about the pathetic state of affairs; and feedback always have fallen on deaf years. Still I will scream till my last breath in this company.
Immediate Cause: The bus service + food provided by the company for a recently organized event & for first time taking my own transport during team outing (w/ family)

Long Term Causes
  1. Damage to my car while following one of company's 'Dinosaurs' process
  2. Discussion for keeping the air conditioning on after 6 pm in office
  3. Discussion for improving the transport system of the company on team outings.
  4. Mosquitoes in the building because we like a jungle like aesthetics inside the building
Our history teacher at school used to say, "...for both the world war which has happened, there are immediate cause and long term causes..." and from there I realized for every reaction there has to be the two 'causes' namely the immediate one, which triggers the 'final-nail-in-the-coffin' and long term, which builds up the whole issue.

Let us start with the immediate cause - Today was for the first time we had team outing where I used my own transport. Total time taken on road = 3 hrs, total distant covert = 100 kms approx. But at the end of day I felt, the pain in the legs driving in Bangalore traffic is far-far less then the pain generally in head and body by using the company provided transport. We didn't get the company transport, because we planned it with our family. Now compare it with the function which was organized by the company last week and because it was a mandatory event, I used the company provided shuttle for the transport. Here is the list of events which happened:
  • Company provides all routes which different buses will take.
  • Company asks all employees to register for bus service to understand the logistics and specify the pickup point explicitly. 
  • Company asks employees to be on stop 5 mins before pickup time.
  • Morning pick-up time is 6:57 am from my stop. I am here by mistake at 6:30 am. 
  • The crowd of  30 odd people builds up around 6:45-6:50 am
  • First bus (route 43) is a bus which can't hold capacity of 30; was already full; arrives more than 5 mins late. Around 7:20 am
  • Calling the helpline provided, one single formulated answer 'We have enough bus, it will reach you'.
  • Another 52 seater comes around 7:30 am. Considering I should have been on stop around 6:52 am, around 38 mins late. 
  • The bus gets full and we don't pick up anyone on the way (God only knows what happened to people after our stop!!!)
Sadly things doesn't end here... We had to return too right in the same transport. These are the list of events happening in the evening:
  • According to the known information (here I might be wrong), we were supposed to leave for home at 9:30pm. We didn't till 10pm.
  • We were coming from Tumkur Road to Marthahalli to Kundhanhalli. First person who got down of our bus was at Total Mall on outer ring road. 
  • I was mostly sleepy in the bus, but when I woke up, I saw my college road and we were near IISC. I was like "Why the bus driver going this way?"
  • Then I saw 'Sanky Tank', then I saw Cauvery Theater junction and then the driver turns towards Palace Ground and finally I got restless and asking some colleague to talk to driver in local language.
  • Finally when the driver crossed Hebbel and we were about to get on the Elevated Highway, someone knocked some sense into him and we took a long U-turn heading back on to outer ring road. 
  • If anyone can understand the Bangalore roads, they will know we wasted lot of time. In the morning and now in the night, just because my company can't handle travel basically.
  • Finally, I dosed off only to think we are on the right way. But then another bus/truck/lorey hit our bus and knocked off the side mirror, I woke up worried, now an employee is injured too. Thank to which ever God who was watching over us, no one got injured. I stepped out of my bus around 11:40 pm. 
Food!!! OMG! Can there be a bigger fish market than this. Hot, chaotic and at times no-food. Again bullet points to cover them all:
  • No spoons; if spoons are available no plates
  • No food at most of the counters. If something is available, something else isn't. 
  • Lunch I never saw 'chapati' -- Every one I guess at rice. Boring sessions (personal opinion), then rice which cause more sleep. 
  • Dinner lesser chaos. 
  • Food quality was even pathetic than what we get in office and that is saying something. 
I have attended in past other events by my company and every time I have gone to the delegates sections to have the food. This time sadly being the new place had no idea where that was. Warning: if you are an employee of my company, please either become delegate or don't come to the event. 

The next point I am talking has actually made me change my behavior about the company assists which they have given to the employees. It is more or less a closed discussion from the Management point of view. They have silently washed away their hand with the problem and only silver light I can say is the HR who has been supportive towards my cause. We have an XYZ policy which required company security guard touching my car which I used to commute. Because of the XYZ policy, some part of my car got damages because the security guard didn't do his task properly. The management says 'We are not asking you to come by car, so we are not responsible for it'. The person who said this, when he said that, looked exactly like the insurance guys when we expect some claim to be settled and they want to wash their hands by finding fault/loop-hole in the situation. He also said that personally I feel XYZ policy should be scrapped, but it is being done for a long time and we have to check with everyone around. This is a classic example of Indian Parliament where they just talk and nothing is done to fix common-man problems. My HR at least called up from US and discussed over the phone and requested some time to discuss with the security guy. Let see if ever I hear anything related to this...

Other points:
  1. I have stopped staying beyond 6. There are big mosquitoes and irrespective of what actions company takes, somehow the remain bugs are always attracted towards my blood. I have seen friends having malaria and I don't want to go through it.
  2. It gets unbelievable hot after 6 in office. So much so that it is suffocating. I have got a personal fan, but due to shortage of fans in company, it is horrible sweaty environment. 
  3. The coffee vending machine, the coke machine everything is shutdown at 5:30 pm. So get your own caffeine if planning to work post that along with of course the office mosquitoes. 
  4. Cab drivers in office... for me this point is closed more or less. Until someone will die due to the rash behavior of facility in our company 'No' one will wake up. I know this will happen one day, while I hope it never happens, it will and my heart knows this will. 
    • Why it is close - Previously said, I felt much better driving on my own now.
    • What is bad about it - talking on mobile while driving, driving fast (had to hold on to seat belt when being dropped to airport).
    • Why not complain about it - Does it help? Here even I am in plastic state. They come, they go, cab drivers still remain the same. Employee should be given the power to say to the driver, 'if you do this thing wrong one more time, I will report now'. No money paid if any complain comes. 
For my colleagues, something will happen. I will from now on come in my own car. If at any point of time someone will ask me to drop, I will politely refuse it. Because I never got support in getting another feedback, another voice and this includes even female employees too. It would be hard to explain it to them why, but for all past, present and future teammates of mine, extremely sorry, but I had to make a stand and this is just the beginning.