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.
No comments:
Post a Comment