The Dialog

I logged into our application and was greeted by a new dialog. When I see something new, I normally scrutinise it, and check out its functionality. I guess I’m quite inquisitive.

The thing is, the dialog also caught my attention because it looked really odd.

My eyes were instantly drawn to the link which was in a strange position, and the font looked very large. I loaded up the code to see what was going on. Usually, we use Tahoma 9, but this dialog was using a combination of “Arial” and “Microsoft Sans Serif”, then the link text is 10.5 rather matching the other 9.5 (which is wrong anyway because it should be 9).

The buttons look a bit dark: they are using “Light grey” rather than the standard “Control Light”.

I also thought the Email label was a bit far away from the text box. The buttons are quite far away too.

So I quickly made a few minor tweaks to illustrate how I thought it should look like.

I probably should have left the text in bold, but I had already deleted my changes after taking the screenshot

It’s not perfect, but closer to what I expect to see. It’s easier for me to judge because I’m used to our application. Moving from the original dialog to another looks jarring since the fonts were clearly different sizes, whereas you readers have no comparison.

How does an entire team of developers and testers not notice these differences? I quickly checked the other dialogs they added and saw similar problems there. Sometimes spelling mistakes, grammar mistakes, randomly double spaces between words, and some uncentered text:

It’s a complete lack of attention to detail by the entire team really.

I contacted the team, which was led by Colin who is infamous for his lack of attention to detail. His response was that he “was just following what the User Experience team gave him”. I checked the documentation he shared, and the mock-ups looked like how I imagined them to be – and not how his team had implemented them.

One of the Testers said something along the lines of “well, we debated these issues within the team, but ultimately – the Product Owner said it was fine”.

When they did “fix” it, the developer didn’t send the review to me, but I noticed it and jumped in. It had already been approved by a member of their team, but was it actually good? Would it meet my standards?

No. He had barely changed anything.

The fonts were still the wrong style and size, the buttons were still the wrong colour, they were positioned incorrectly. He had even changed a few things no one actually told him to change – so made it worse.

Colin Promotion

I did mention that Colin joined this team because he saw it as a good opportunity for promotion. I thought he was absolutely nuts because he didn’t even deserve his Senior position, yet he was aiming to be among the “big dogs” in the company (often known as Principal Developers). I’m sure you will agree that he has ‘ideas above his station’ if you read the stories I write about him.

Well, now I have egg on my face – because he has been promoted yet again, and I’m still not a Senior. He is two ranks above me now, can you believe that?

I sent messages to some of his old colleagues to inform them of the news. Usually, if you tell someone about a promotion, you will get neutral responses like “ok, now I know who to talk to about X”, or maybe some positive responses like “brilliant, he really deserved it”. Out of 7 responses, what percentage were positive or neutral?

0% positive, 0% neutral. 100% negative. Some people even accused me of lying. I don’t normally put swearing on the blog, but I’ll include this one. Here are the responses:

“What!? I don’t know what to say to that.”

“haahaha are you fucking joking?”

“wtf..what is wrong with the managers?”

“Be prepared for more mistakes”

Is he your team leader? That should work out well

“wow, how did that happen? God help the world”

“Don’t lie”

I’d like to point out all I said was “Colin has been promoted”. I didn’t tell them what I thought, or preceded it with any statement to influence their opinion.

So the promotion definitely doesn’t have the backing of his colleagues. It makes you wonder how a promotion can go ahead when it is unanimously deemed a bad idea. Well, I’ll keep trying to think of how to make an accurate and fair promotion process.

I did have a conversation with my manager to ask why my promotion didn’t happen. He gave me the usual response I’ve heard in the past to do with budgets and no free spaces for that role. I pointed out that Colin has just vacated a Senior position which I can have.

He was still adamant that the budget was gone and there’s no free spaces anyway. He promised he was doing as much as he could to promote me, and he said he was constantly asking the Head of Development to promote me.

I have to put faith in him, because later that day the Head of Development sent me a message saying how she understands “I am doing a great job and it is appreciated”.

The funny thing is, I’m not even doing a good job at this current moment. I’ve had lots of annual leave, and haven’t had much work assigned since we decided to cut the scope of our recent releases. I’ll probably write about this in more detail shortly.

Missing Update

I received a review from Colin which was modifying an internal tool. I have never made any changes for this tool, but I have had a nosey at other changes to have a vague idea of the approach to modifying this.

I point out that his SQL patch was missing an “update” statement. (Ideally, maybe someone should add a database trigger, because manually adding this extra “update” statement to every patch is a bit silly; but hey, that’s the current process).

He replies back asking why he needs the update. Before I had even responded, he had made the change anyway. So he has no idea, but is happy to do what I say!

He also said “I have never made a change for this tool before”. I knew that was a lie. I could look at the ‘Completed Pull Requests’ and find 1 change that he did a few months back. I really haven’t made a change to this before, and I know that this statement needs adding in, it’s not really an excuse.

I explain that if you look at all the other patches, they all have it in. I also linked a recent review which was done by the “Module Expert” where he flagged this as a problem, and has provided a basic explanation of what it was for. This Module Expert was on holiday for the week, so we couldn’t ask him, or get him to review it; so Colin has to make do with me reviewing it.

3 hours later, I get another Pull Request from Colin. It’s a separate change, but it’s another patch for the same tool. It doesn’t have the “update” statement in.

Instead of shaming him on the Pull Request. I send him a message on Slack asking how he managed to forget. He then tells me it isn’t needed because “it is a different area”.

No idea what he is on about. If he really thinks it isn’t needed, then why did he change it as requested in the last review? If I am wrong, then he shouldn’t have made the change, and he should have responded telling me that. Of course, if he sends a review without this expected change in, then I’m going to question it again, aren’t I?

Product Names

Let’s say that the company I work for is “ACME” (classic fake company name). Our existing product is called “ACME Pro”, and our upcoming product is ACME-One.

In the past, we have had inconsistent branding, with the company name written as ACME, Acme, and acme. We have tried to be more consistent and have discussed the importance that the new product is only ever gonna be “ACME-One” and the hyphen is very important.

Colin has been doing some work in ACME Pro, but it has some kind of integration with ACME-One. He had a database change and was populating the new table with values “Acme Pro” and “ACME One”.

I point out that the casing is wrong with the first product, and he has missed the important hyphen in the second product.

It would take him a few seconds to change it, whereas leaving it like that means it will probably be wrong for a long time and annoy pedantic/perfectionist people like me.

He replies “this isn’t user facing text, so it is not an issue”.

He really doesn’t care about quality. Also, one of the database columns is literally called DisplayName. Who is the text displayed to? If it isn’t an actual end user, it’s going to be an employee using some kind of configuration tool; and that is still a type of user.

It’s also annoying for writing SQL queries, because you may type “where DisplayName = “ACME-One” but it won’t find it because the stored data is missing the hyphen. So you have to be aware of the misspelling in order for data to be returned.

All Nighter

After my important bug fix was complete, it needed urgently testing, so a Tester worked overtime on Friday night and Saturday.

During testing, he found a bug, but it was completely unrelated to my fix. Still, he wasn’t to know that, and so when he raised it as an issue, my manager was panicking and trying to contact some developers.

I didn’t see the message until Saturday 11am, but when I logged on and investigated it, I saw another message from my manager to liaise with Colin. Colin loves his overtime so had jumped at the chance to get involved.

When I managed to contact Colin at around 11:45am, he sounded like he was falling asleep. He then told me he was working 10pm to 4am to work out what was happening.

To be fair, he didn’t have the advantage of knowing what the original bug was or the impact of my fix, so I assume he spent a lot of time investigating that. The thing is, the only conclusion he had was that “it wasn’t caused by your change”. I worked that out within 30 mins; I didn’t need 6 hours.

The thing is, there’s no way you can work effectively that late at night; given that you have already done 9-5, and you have it in your mind that it’s now the weekend. To get back in “work-mode” and look at code through the early hours of the morning – it’s just madness.

The thing is, I worked on an important project with Colin a couple of years back. There were major problems with the code which were often caused by Colin. I fixed them during work hours. Colin was spending a few hours extra each night in overtime fixing other problems. He would then turn up late the next day, looking completely tired, and then wrote more crap code… then had to sort it out in overtime. Then it’s an endless cycle. If you want quality code, then overtime is not the answer.

August Retrospective

As part of “Agile Development”, you have a meeting called a Retrospective where you look back on things that have happened over a certain time period (like two weeks), and say what happened, what went well, and what didn’t go well.

When we worked in an office, we booked out a meeting room and wrote on Post-It notes and placed them on a whiteboard. Since we are working from home now, we needed an online solution. We used the Retrospective board on Microsoft’s Azure Devops; which worked well.

There were a few interesting points I wanted to note down. One point I strongly agreed with, and the other two points I think either: I am deluded, or the rest of the team are.

“Part time Product Owner”. When our team was formed, we were told our product is really important. If it was important, we would have the correct staff in place, with a Product Owner in charge of providing us with requirements, or making decisions on well-defined requirements. At first, we didn’t have a Product Owner. Then later, we got one, but she was split between two products and we were always low priority. Due to this, some of my work ended up being shelved because I had implemented the requirements I knew about, but I knew there was much more to it, so raised questions that were never answered.

“Need to stop working at pace, otherwise we will all burn out.” This is absolute nonsense; we are so slow. This is basically a reference to what the Head Of Development said in Team Summary, but other managers have used the phrasing “working at pace”, so now people in the team are regurgitating it.

“Code Analysis work going fast” First of all, the people responsible for analysing the data were dragging it out as long as possible, see The Code Analysis Meetings (It’s a great read [if I’m allowed to promote my own blog]). Also, Colin has been leading a small team to actually fix these “problems”.
A) they are making changes manually and progress is slow. The changes are simple, and they can get Visual Studio to fix them without extra input.

B) Colin was taking days to review them, so I ended up stepping in and reviewing the code for him.

Bonus Chuckle

We get to the end of the retro, having gone through the full board. The final stage is to vote on the items that are suggestions on what to “do”/”stop doing” in future.

“I can’t see my items on here”
Becky

It turns out she has added her items to another team’s board. 🤦

I don’t get how we can go through the ENTIRE board and only then does she realise that we haven’t talked about the four items that she added.

Team Summary

The team is showing unwavering commitment, innovation, resilience, and drive to deliver continuously. I’ve never seen anything like it in the years I’ve been here.
Head of Development

I always say that managers often show a massive disconnect from reality. They seem to praise when the team has performed poorly, and I think this is another case of that. I went through our team’s changes in the last month. Merges are trivial and I don’t really count them as real work, but I’ve included them in the table anyway.

Here is the analysis:

Name	Merges	Fixes	My View
Me	1	4	I’ve been disappointed in my productivity. However, I haven’t done that bad when compared to everyone else. Additionally, I have got loads of changes in a branch, on hold; awaiting confirmation of actual requirements.
Senior Dev	1	11 (mainly small items)	Decent work, but really only cherry picking “quick wins”
Colin	4 (made a massive mess of one of these, made a bit of a mess with another. I think the other two were primarily to teach people how to merge [ironically].)	5 (I believe 2 of these fixes were issues he created in the other 3)	Colin wasted a lot of time by making a mess of a merge which introduced at least one bug, and he made a mess of one of his other changes. He claims he has been more productive whilst working at home.
Colin 2	0	3 (1 of which was removing an unused using statement)	With only 2 real changes, one of which was small and it didn’t work properly; this is terrible performance.
Rob	0	2	Rob has been real quiet. I think he had a bit of time off work, but still, this is poor
Beavis	0	1	Beavis was primarily just making excuses why he can’t work. To be fair, there was one week where he was doing some other work for another team.
Total	6	26

Our “drive to deliver“

So in a month, we haven’t done much work. I’d be interested to calculate what the average amount of fixes developers do each month. It’s a bit meaningless because a fix could take an hour, and another fix could take a week. However, you would think it would average out over a period of time.

I’ve never seen anything like it. I might use that as a recurring phrase from now on.
My manager actually said to me that my efforts “haven’t gone unnoticed”. I didn’t bother to correct him. I think I need to play up the delusion to try and get a promotion. Honesty never got me anywhere before.

“I did not realise I had to check it in”

Beavis was assigned a fix for a release. We support multiple versions so it needed to go into the “Release” branch (older version) and the “Main” branch (current version). Personally I think it makes sense to make the changes into the Main branch, then merge them into the Release branch. It probably doesn’t make a big difference really, but I told him that.

Beavis decided to ignore me and just check in the fix into the Release branch.

A few days later, one of the Release Managers tells Beavis that his change is missing from the Main branch.

“I did not realise I had to check it in”, he lies.
Beavis

The thing is, I then check the difference between Main and the Release branch and there’s two other check-ins from Colin and neither of them have checked it into Main.

I don’t understand how we have these developers that have worked here years and they still don’t understand our process.

The Code Analysis Meetings

Our Team Lead had been hyping up how important it is to improve the statistics of our codebase. So we have a report that runs and gives you metrics about duplicated code, “code smells”, possible bugs, test coverage etc.

Colin volunteered to lead on this. I know that he is just trying to impress our manager to try and worm his way into another undeserved promotion. The thing is, he isn’t even thinking about what he is doing.

There’s been 2 meetings per week, and it’s been going on for 3 months. I wanted to know what was going on because we haven’t heard any outcome from the meetings, and the statistics haven’t improved either.

Intervening

I asked one of the attendees if they had discussed a particular rule that was flagged by the report, and told him that if we suppress the rule, it will improve the metrics by 300 or so. He told me to come to the meetings.

So I join the meeting, and ask them to investigate the possibility of suppressing this rule and people seem to think it is a great idea. No one had any other new ideas, so then Colin said we would continue going through the report.

I asked him to explain the process since it was my first meeting. He said there are different severities like low, medium, high, critical, and managers only care about the two highest categories. So he was going through each rule and commenting on them saying they can be changed to Low, or that we need to fix them.

So we start looking at each rule violation, and there’s about 8 people on the call; mainly developers but a few interested testers, and 2 managers. I say “interested” because they have turned up to the call, but when Colin asks people to discuss it, no one can make a decision. Colin kept on trying to describe what the code was doing but made so many mistakes, I had to correct him several times.

I was basically taking over, but kept on asking for other people’s opinions, but people seemed pretty indifferent. The call had gone on for nearly an hour and a developer hadn’t said a word, so Colin accused him of being asleep. The developer said he was awake, but then continued to stay in silence for the rest of the call.

I was told there was another meeting in a few days time, and it would be more technical, so I agreed to join.

The Great Realisation

That meeting was basically the same people, but excluding the managers. Colin continued going through each rule violation again. The conversation that followed roughly went like this:

Me: “Hang on, this is taking forever. We are seeing the same type of rule violation and you have gone through about 15 of them now.”

Colin: “Yeah, there are loads”.

Me: “This seems like it is gonna take all year. How many violations of this particular rule are there?”

Colin: “4000”.

Me: “Hang on, let me get this right. You are going through each of the 4000 violations, analysing the code, and trying to decide if you should mark it as Low severity or not?”

Colin: “Yep”

Me: “Don’t you think it is stupid?”

Colin: “That’s what managers want us to do”

Me: “No, the managers want you to decide how important the rules are, not how important each particular violation is. If they were aware there’s 4000 of the same rule, I’m sure they wouldn’t want you to do this. Why don’t we just look at the rules? How many rules are there that are being flagged as High or Critical”

Colin: “5”

Me: “So you have had about 12 meetings to discuss 5 rules, and you haven’t even gone through 1?”

Colin: “Yeah”.

Absolute waste of time. Just think, if there’s only 6 people and you paid them £12 an hour, and had 24, 1 hour-long meetings that they attended – that’s a cost of £1,728. But then sometimes there would be more people attending, and you had the expensive managers too. What did they achieve until I came along? Nothing. No one questioned it.

The thing is, we are concentrating on the wrong thing. There’s plenty of bugs to fix which bring value to the users. Why are we wasting time tweaking things that don’t need to be changed? The crazy thing is, we are spending all this time talking about doing it, and it isn’t being done.

The Efficient Team

In the next meeting. I told the manager our new approach, and also raised some of my concerns with how much importance we are placing on this. She didn’t care about my concerns so that got ignored. What she did say was “you guys are becoming an efficient team”.

Is that even serious? Months of wasted time. The words sound sarcastic to me, but I think she was being serious; the tone sounded sincere.

So in conclusion: Colin was just trying to impress the managers by taking the lead, and so was everyone else really; they were on the call, but they really had no passion for what we were doing.

Just Copying What Was Already There

My manager calls me and says there is a bug that might end up holding the release, and wondered if I can help. He said it was found when testing Colin’s work, but it might not actually be related to his changes.

Colin had been given some other work and he was taking ages on it,so wasn’t available to complete this work himself.

So I call Colin and ask him what this bug is. He sent me the description from the tester (Becky) which was next to useless, he showed me his recent changes, and a specification from his project. Colin assured me that his changes should work, because he just “copied what was already there”.

It seemed like everything I needed, so I got digging into the code and testing it out.

It didn’t take me long before I realised what Colin had done. There were two scenarios that he needed to check. By copying and pasting what he saw in that file; he was just covering one of the scenarios. The other scenario was actually in another file, and he would have realised that if he actually tested it.

The thing is, my first thought was to add a unit test to cover the scenario. I checked for existing unit tests for that file, and there were some existing tests. Colin hadn’t bothered adding additional unit tests; which would have made him realise that his changes didn’t cover both scenarios.

Then days have gone by, the manual testers have finally got round to testing out his changes, and logged this issue just days before the release.

Then I have to save the day once more.

It’s so annoying/stressful when you get given a bug to fix with strict deadlines, but luckily it was very easy to fix. If Colin had shown a bit of effort, then we wouldn’t have been in that situation.