Obsoleting Your Codebase

William sure has a knack for saying the wrong thing, leading to lots of wasted time.

His team had been using our repository to check in their example code. Our repository’s purpose is example code, so it fits nicely in there in my opinion.

He comes over to my desk and claims that developers will wonder where they need to go to find the example code, so he wants them to go to a new repository he has just created.

How are people going to find his repository if they somehow can’t find our repository?

Well, his idea is that his repository will also deploy a website with instructions on.

How are people going to find his website?

Well, he hasn’t thought of that point. He also stated that when he moves the code to the new repository, it will make our codebase “obsolete”.

I was really annoyed by this. Firstly, if you create a new repository and move all the code from an existing repository, all you have essentially done is renamed the repository (and wasted a lot of time). Secondly, why does he think his repository is more important than ours? Surely it should be agreed with the team, rather than just pulling rank and forcing his ludicrous ideas through.

I firmly put my point across and then he replies:

“I’m not making your codebase obsolete, I’m just moving my code out of it. None of your code is going anywhere”.

WHY DIDN’T HE JUST SAY THAT THEN!?

I still think it is dumb creating another repository, because now there will be two repositories to check for example code, and all the example code is currently in the same location. If a website is actually helpful, then it can be added to our repository.

Mini Musing #6: Expenses Risk

I overheard a conversation between a Tester and his Manager. The tester explained that he had purchased an online course on a programming language and he asked if he could claim the money back on expenses. When his Manager expressed doubt that the company would cover it, he then said “well, never mind, I knew it was a risk.”

A risk!?

The way I see it, he should have bought the online materials to become more knowledgeable because he is interested in the subject, not because it’s simply something he could get for free. Describing the purchase as a “risk” shows the wrong attitude in my opinion.

I do wonder if he regrets the purchase and wanted to get his money back via any means necessary.

How To Assign A Bug

I was asked by Simon to check source control to see if there was an obvious cause of a problem reported by a customer. I looked through the code and couldn’t find anything that stood out.

I heard Simon talk on the phone and it sounded like it was an important issue. I asked him if this was high priority and he said it was.

So I did a bit more digging, then Colin came over. Simon had also asked Colin to look into it, and Colin said to me “don’t worry about it, I’ll look into it.” So I went back to my normal project work.

An hour or so later, I heard a tester talk about the issue. I was interested in how the situation was progressing, so I went over to ask them about it. He said he had just started looking into it, but wondered if I had recreated it yet. I tell him; “I’m not looking into it, Colin is”. Simon then says “you have to look into it, Colin’s manager won’t let him work on it”.

“What the hell? Why wasn’t I told?” I then asked if there was a work item with information about the bug. “No” replies Simon.

Back in my day, we were told that we couldn’t work on anything without a bug being logged. It makes sense, all information goes in the item, and then if you are off sick, another person can easily pick it up.

If there’s no bug report, how do I know what the problem is, or perceived to be? Anyway, I ask the tester, and he shows me a Slack conversation from Simon. If I was always supposed to be looking at this issue, why weren’t I added to this Slack conversation?

I begin setting up the data to try and recreate the issue, when Colin comes over. Even though he isn’t working on it, he wanted to give me some advice. He starts talking about a recent project that was completed. I ask:

“What are you on about? Is this relevant to this issue?”.

“Yes, it’s in the email thread”.

“What email thread?!”

So even though it was decided that Colin couldn’t look at this issue, he was involved in an email thread. The tester was involved in a Slack thread. I’m not involved in either of them.

Again, how can I be expected to recreate an issue, when I don’t know any of the details? Also, it is pretty urgent. There’s a call tomorrow with several people from other departments; support staff, important managers etc. I’m supposed to explain my theories of how this problem was introduced.

Absolute farcical.

Later on, I’m at a different manager’s desk, and he has an email open. It’s an email thread between a few managers discussing if Colin can look at the issue or not. It’s not just Colin’s line manager, but other important managers within the department.

So much time wasted trying to decide which person should do the work, meanwhile there’s no process that is followed to actually assign the work properly. It’s thrown between verbal, email and instant messaging.

How difficult is it to log the issue properly, then find a developer that is available to look into it? It’s not like we’ve never seen a bug before. What happened to the “tried and tested” process?

Fighting His Corner

A few months back, there was a decision between two technologies, lets say it was a debate about Docker and Kubernetes. It was decided to proceed with Docker.

A manager, John said that he has instructions “from above” that we must use Kubernetes. Another manager, Jane seemed to protest about it even though it wouldn’t be anything to do with her. I was confused by this. It seemed really out of character and she didn’t even know the reasons why Kubernetes was dismissed. So it’s not like she actually had an opinion on the matter.

Anyway, further debates were had between John and a Senior Developer, and then I heard the Developer say that “John must go talk to Roy” – who was the major influence on the decision against Kubernetes.

Aaaaaah! that explains it. Roy is Jane’s boyfriend and she was defending his decision. That’s why she seemed belligerent.

It seems to be becoming a bit of a trend that people are supporting their friend’s ideas, blindly supporting a technology just because it appears trendy, or using unsubstantiated claims to support an idea.