You know management doesn't have a clue when . . .
Today management put out a 15 minute fiscal year in review for our primary project. Intent is to switch the DB of our primary product from legacy home grown (30+ year old) to a more modern one. Toward end of accomplishments this director listed the conversion of one of our larger clients over to the new system as an accomplishment. Problem is, it was done by accident! They were not intended to be part of the auto migration process and were supposed to be exempt from it! And yes, they are completely pissed off about it. It has been nothing but production headaches for them (including one today that was being worked when this accomplishment was being trumpeted) including some corrupted data and lots of processing slowdowns.
This really left me with a bad feeling in the pit of my stomach. If this VP doesn't understand that this occurred because of an oversight and is an ongoing issue so is not something to be touted as an accomplishment, what else has he been misinformed about?
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.
Why our company is failing at Agile
So on Tuesday and Wednesday of this week I was bombarded with questions concerning a project we worked on for inclusion in the release we are about to ship. (Our company has to ship our product in testable releases to our clients due to regulations.) The people asking the questions attended every design session and demo, but now 5 months after the work is complete they are asking detailed questions about the functionality. Why? Because now they need to update the release documentation. Why these actions were not done at the time of the project is a mystery to me. This is one of those processes where the people involved have not adjusted their thinking away from the Waterfall project / release model to our current Agile-ish model. The documentation was not updated in parallel with the development, but instead is now being updated now that they are finalizing the release and it is 'time' to update the documentation. So I spend many hours going back over what we implemented to answer these questions, and in one case simply demo'd the functionality as it exists in the product. Waste. Of. Time.
