The case of the one hour build

It was 6.30 in the evening, time for our team's daily update session. I listened as the team went through their updates, nothing out of the ordinary so far. Then A started his update, starting off by saying he had fixed some of the bugs that our BA had pointed out the previous day. He shared his screen and proceeded to click into the web app he'd been developing. An error. And another one. I clicked my tongue with some irritation. This had happened yesterday too. And a couple more times the last few times I joined this meeting. And given that this was the main session where we shared our progress with the others, it would almost mean that A hadn't shown any meaningful progress over the past week.

As the team attempted to just move on to the next person, I called out.

"Wait, I have some questions."

I think there was some trepidation in the air as the team expected me to go off on one of my rants again. Which would be correct, given what I'd seen.

"A, I have no reason to doubt that you'd been been working hard on this. But the fact that you're unable to show it to us just means that you've probably not been building the app and testing it before you enter this session. Can you tell me why?"

A, a junior developer who'd just joined my team a couple of months ago, couldn't answer. Probably afraid I'd chew his head off at any excuse he could come up with.

After 10 seconds of dead air, A's supervisor G nervously spoke up.

"Ummm, we usually do a daily build at 5.30pm daily..."

I immediately interrupted, "... And how is that a good idea? You obviously had no time to test the application before our daily sync up session. Given the number of fixes A had to get done, I would expect him to test each fix individually, no?"

"Yes, but the build is taking quite a long time, you see..."

"Be more specific. How long are we talking about here?"

"...It takes about 30 minutes to an hour to build each time..."

"What? C'mon guys, I know this is a Java program but this is ridiculous. What exactly is going on in the build? Ya know what, forget about explaining. Let's just wait until the end of this session and you guys show me what happens in the build. Move on, please."

I was getting pretty irked by this time but I waited until the end of the meeting. No sense involving the rest of the team in this. At the end, A pulled up his screen again and started the build and we waited. And waited. And waited. After 3 minutes, the gradle build was still in its compile phase.

"A, can you bring up the task manager? I want to see what's happening in your comp“

True enough, 8 CPU cores were chugging away at full 100% utilization. My eye blinked in disbelief. Seriously? This isn't exactly a high end laptop but it's still running an 11th gen i7 CPU. Not exactly a slouch.

"What the heck is this laptop running? Can you show the list of processes running?"

I let out a sigh of exasperation when I saw the list. Some anti-malware tool was taking up 30% of CPU. Windows Defender was taking up another 30％. Tanium was taking up 20%. Gradle itself? A measly 4%.

The gradle job itself was done after about 10 minutes. Then there was a job to pack the binaries into a docker image. It took well over 20 minutes to pack a 200MB uberjar into the image.

I knew that our laptops were fairly handicapped by all the security measures we'd piled on over the years but this is absolutely ridiculous. If A had done what he was supposed to do and run a build every time he fixed a defect and compiled the app, he would've spent half the day swishing swords while waiting for the compiler to get things done.

"A, it's ok, this shit isn't your fault. Send me the screen caps of your CPU utilization and task process list and I'll handle it from there"

The next day, I had a word with our laptop administrator and showed him the evidence I collected. To his credit, he didn't try to make any excuse and said he would escalate this to global. He had gotten complaints about this in the past but nobody was able to send him any evidence and he said global refused to accept the complaints without evidence. That's easily rectified. I got a couple more kids to do the same compilation on their Windows laptops and sent him all the screen caps. Let's see if global ignores us again this time.

I also spoke to my infra team and told them this is evidence enough that we need to get back to getting our Coder initiative up quick. Being able to run development remotely on remote environments unencumbered by lacking local facilities would help a lot.

But most of all, I was glad for once that I waited to see some real evidence before ragging off on some poor kid who was trying his best to do good work on really crappy hardware. I hope things will get better, A. Fight on.