Apprentice Insanity

An apprentice sends a code review with the following code comment in it:

“Need to check this logic…but right now; I may be going insane. Wait, WTF is this?”

Instantly, I doubt how good the rest of the code is. I wasn’t assigned to officially review it, but I knew the Lead Developer would tear it apart. Not just for that comment, but the Apprentice had written this as a disclaimer:

“There are no new unit tests because this will be submitted later. This work needs to be quickly checked in and tested.”

Even though he had already technically missed the deadline. Maybe he got special permission from the Product managers, but if not,  he had at least 2 weeks to work on it for the next release. 

Cutting unit tests probably cost him time in the long run. I wouldn’t imagine he wrote all the code and just tested it once. It would be a case of implementing the solution in stages, making tweaks and repeating the same manual tests with each change. If he had written the Unit Tests early, he could have run the tests as he is refactoring and adding features. Then in the end he would have fully tested code which works. Instead, he has untested code which we aren’t confident if it works properly, and wants to check it at the last minute with less time for the Testers to run manual tests against it.

3 weeks later, he still hadn’t checked it in. Probably a good job this change got rejected by a Lead Developer for not having Unit Tests.

I’ve seen this kind of scenario before where people cut tests or a feature that was “nice to have” in order to meet a deadline. They say they will finish it after it is checked in, but usually something with higher priority comes along and they do that instead. If it wasn’t important enough for the original deadline, then I guess it is deemed as extremely low priority by any manager. Then it never gets done.

It’s funny how many code comments you see along the lines of “//Check what this does”, “//Finish this”, “//check the performance”, and then you wonder:

1. How did this get checked in? (well, probably fast-approaching deadlines like I’ve explained)
2. What feature is missing? Is there a bug with this code?

If you write unit tests early, then you achieve a higher quality solution earlier on, and you gain confidence in the code. 

The worst scenario is: complicated code with no tests, written by an apprentice, who makes a statement which expresses his uncertainty if the code actually works.