Another working remote Fail and another Agile Fail
So yesterday I came home and cried I was so frustrated with the day.
My boss chimed in on a client emergency that sent the team working on it down the wrong path for half a day. I knew his analysis was wrong the instant I read his email. If he was working in the office, we would have had a personal discussion before providing guidance to the team, but because of working remote, and him being 2 hours ahead the team working to fix the client's issue wasted half a day on the wrong analysis. The day already sucked, I wasted a couple hours of my time correcting their course, then I started the code review.
There is a project that is reworking our legacy trouble reporting code to provide it in JSON formatted output in addition to the legacy text output. The JSON output will be used to transmit the information from our clients back to our in-house systems for analysis. (This is something we've wanted for years, a good improvement project.) Last week I was asked to review the initial set of changes and found code that, by analysis, I could tell didn't work. The developer tasked with these changes is known to take whatever shortcuts that he thinks he can get away with, writes lots of repeating code (instead of methods), has no sense of separation of concerns, and does not adequately test before submitting code. He was in the group of developers who were the last to be transitioned from Waterfall development to Agile, as we "need to be uniformly an Agile development shop." So I provided feedback in 23 code review notes and a 2 hour discussion / walk-through of the code to try and fix this. Of primary concern was lack of use of a JSON formatter for output (our primary development language does not have a library available) and repeating code throughout. In the walkthrough I gave detailed information on how to build this so it would be flexible going forward and robust in its processing. The short of it is, when reviewing the code about half the information I provided (all of which was written down) was followed and the rest was not. He also did all of the changes in the module and submitted them, instead of a minimal set and having me check for correctness before doing the rest of the module. It is 1102 changed lines in a single submission. This is code that has to work every time, when this runs we are in a situation where a running, user facing program is about to exit due to internal error and we have to have a record of why in order to attempt to diagnose the reason (our language is not memory safe, so memory related issues are the primary concern.) I provided another 7 notes before I just gave up. I asked about why my guidance was not followed, and was told that he was, "in a hurry because this is Agile and didn't feel the need to follow everything [he] was told to do." The stuff he skipped is going to bite him in the ass when he moves onto the other modules, and I don't have the mental attitude to deal with it.
This code has already failed to work in-house, as (because of Agile) we are checking into our Trunk directly. I expect it to periodically fail in production when this code hits the client systems. Before Agile, this code would never have been incorporated, and this idiot would have been shown how to rework it before it was. Now, he checks into Trunk and the rest of us have to clean the mess up. His team is lead by someone whose errors are simply ignored and once they have made a mess of something assignments are rotated and they, somehow, are never left supporting the changes they have screwed up.
posted by MrPopman @ 6:35 AM
0 Comments:
Post a Comment
<< Home