The Changes #2: Demotions

Recently, we have a new CTO and a new Head Of Development. Like all new managers with power, they want to make their own changes.

In The Changes #1, I explained changes to job titles of Testers. Some Developers are also affected.

Currently, the hierarchy is basically Junior, Developer, Senior, Principal, Architect. With the new changes, we planned on removing the Principals so they will become Senior.

When I think about it, there aren’t that many Principals, and their job is really the same responsibilities of a Senior. To be honest, there isn’t actually any difference in responsibility between the standard Developer role as well.

I actually like these titles though. If implemented correctly, it gives you a clear indication of people’s skill level. With the new titles, if managers created 2 teams consisting of 1 Senior, 3 Developers and a Junior in a team. If one team’s Senior is a standard Senior, and the other team’s Senior is the former Principal, then this second team has a massive advantage because they have a leader that is at a significant skill level. I know it’s not a competition, but developers will want to be in successful teams.

With job titles, if you manage to persuade a promotion, then your wage should jump up to that band. If you remove the level, then it puts the power towards the employer to suppress your wages. It’s much harder to justify an increase if you don’t accept more responsibility (or have a title that implies responsibility, even if there actually is none).

I can’t speak for everyone, but a better job title is a massive motivator for me. I have been suffering low motivation for a while because my team members see me as a Senior but I have just had the Developer title. It hasn’t happened many times, but there’s definitely been a few occasions where I felt people haven’t accepted my idea because someone with a Senior job title suggested something else – so they automatically sided with them. So I think you automatically gain respect among certain colleagues.

If I had earned a fancy job title and my employer took that away from me, I would be very angry. If it took people a long time to gain that title, it would be devastating. I guess that means that Colin should have moved back down to Senior which is a much more appropriate job title for him.

However, after about a week, this idea was silently squashed. I found out because I asked a Principal Developer what he thought of the demotion, and he said it wasn’t happening due to the amount of negative feedback the managers received.

The thing is though, surely anyone with common sense would know that people weren’t going to react positively. If the managers were willing to back down that quickly, then how did the idea even get to the stage where managers agreed to announce it to the department?

The Changes #1: Attempt To Replace Manual Testing

When it comes to Testers, we have hired some fairly non-technical people as “Manual” Testers, but then on certain recruitment drives, we have hired “Technical” Testers which performed manual testing but also have the scope for Automation testing.

When we announced that we would soon be starting projects that will build our next product, managers stressed the importance of defining new processes and upskilling with new programming languages. Moving into the “new world” where you expect things to be automated; there isn’t much need for non-technical people.

I did warn one of my Tester friends about this – that his days could be numbered, but he didn’t listen. He waited for several months, and then seemed to think “damn, I’d better get learning because there is literally no work otherwise“. Meanwhile a few people requested a promotion so they can be a manager, which is unfair really; but there’s always people that benefit from restructuring.

Anyway, another year has gone by and the projects have been a disaster. I don’t think they really went through with their “no need for manual testing” approach, although some people did move back to support the existing product to do manual testing on a familiar product.

In comes a new CTO and a new Head Of Development, and now, yet again, their new idea seems to be 100% Automation.

I expressed my concern to my manager. It didn’t go to plan last time, and you may find that some manual Testers simply leave the business since they have no plans/desire, or might not have the ability – to do automation.

Earlier in my career, I used to do manual testing and it soon became a tedious and boring job. If you actually find people that do it for a career, then they are probably worth keeping around. In my opinion, you always need manual testers.

Another thing is that you are assigning an inappropriate job title to those people. The automation testers have the weird job title of “Developer In Test”. If you are currently a non-technical, manual “Senior Tester”, how can you suddenly be a “Senior Developer In Test”? This implies that you not only have technical skills, but you have achieved Senior level in it. It’s a joke. Demoting the Senior to the basic “Developer In Test” would make sense but would probably cause them to be disgruntled and leave.

When I previously wrote about job titles, I used Colin as an example. I’d say he was an underperforming Developer, but got promoted to Senior. Simply calling him a Senior doesn’t mean he has better skills. Then another couple of years pass, and somehow he gets promoted again to Principal Developer. I wasn’t happy about that, and questioned my manager. He could only explain it as “we had a vacancy and a strong need for a Principal in the team”. But if Colin was already in the team, what good does promoting him to Principal do? He doesn’t level-up like a computer game character and gain extra productivity, coding skills, code reviewing skills and leadership. We needed to recruit externally to add another person to the team, but also increase the skill level.

So with these new changes, I asked my manager, “why are we changing job titles?” and he said “we are following a new Agile framework that the CTO is implementing”. Surely we can still follow the framework without copying job titles word for word? All it does is cause some staff to be disgruntled.

When another manager was explaining the team structures, he said

“there’s a thin line between “Software Engineers” and “Developer In Test”
Manager

He said that means that Developers can help Testers but then seemed to struggle how to justify how Testers can help Developers – because it turns out they aren’t actually the same.

Conclusion

New managers like Heads of Departments or CTO’s love making changes.
100% Automation is a dream. I think you always need Manual Testers.
Changing job titles can cause people to become disgruntled.
1. It could feel like a demotion.
2. It could feel like more responsibility for the same pay.
Assigning a job title to someone automatically doesn’t give people those new skills.
Testers don’t have the same skills as Developers.

“What interaction have you had with varied stakeholders?”

One of our apprentices said he needs to fill in an “evidence” piece which questions aspects he has experienced on the job. Since he has mainly been studying for exams and filling in forms, he hasn’t had much chance to actually do any real work. So he wanted me to help him come up with ideas of what he can write about.

I don’t think we have that much interaction with people outside the immediate team really, but it really depends on how you interpret the question. I guess this particular question is just about stakeholders which includes anyone with an “interest” in the software.

I always thought it was annoying when we got asked questions like this on appraisals; usually the focus being on people outside your team/department. It’s not part of our job really, since we have a hierarchy so you would just get your manager/team lead to either arrange a meeting, or perform the action on your behalf.

The key thing for developers is to raise questions about requirements with a Product Owner. So if the requirements aren’t clear, or your investigation has uncovered new information – then the solution isn’t as simple as people imagined it would be. Then you could then agree on changing the requirements with the Product Owner, or creating a new “work item” with the additional requirements to implement at a later time.

Maybe you would need to talk to an Architect to come up with an overall solution to a complex problem.

Sometimes we email the UX team for UX designs or to ask the Technical Authors to write us a nice user-facing message to display in a dialog box.

Ideally, in a perfect world, these things would be alongside the requirements since you would think there would be a process before it comes to us. But we never really work like that.

In a recent project, the requirements were vague anyway. It was more like “Feature doesn’t work for certain users” …they want to select a Proxy user and that user’s details are sent in the message. So I made those changes but then you realise that they could want to use the feature, but maybe haven’t configured it correctly. So you need to tell the users. So I’ve put in a message box to tell the user certain config is missing from their user. I’ll need to get the Technical Authors to write the actual message. It should also be confirmed by the Product Owner that they want it to work like that.

A Tester then found another potential issue and suggested we add a default behaviour in a certain scenario, but that would be something the Product Owner decides. Do you want to switch the default, or do you want to just tell the user this method is invalid, and they have to manually switch to a different method? But then maybe we would want to ask the UX team what they think the user flow should be.

I guess the conclusion here is that it’s always hard to know exactly what the system should do. You end up having some requirements but then when you implement it/prototype it, then you realise that there are other scenarios that you should also take into account. So sometimes it is an iterative process: there is a bit of back and forth with the conversations between these stakeholders.

Software Development Interviews

I think a big challenge during the Software Development hiring process is how to determine who is good or not.

Sometimes companies give large projects as a do-at-home test, but this puts people off when they currently have a job and have other commitments that take up their free time.

You could be given a smaller task, but then it may still not give a good representation of how someone codes, and you could easily get someone else to write it for you.

Other companies leave it until the interview and make developers write code in a manner that is completely out of their comfort zone; e.g. using pen and paper, or a whiteboard. Apparently, Google makes you write code in a shared Google Doc.

I’ve sometimes been given a timed test to complete at home. So you are emailed a list of varied questions and have to quickly code them then send them back via email within an hour.

The challenges they make you do can be varied. Sometimes they can be really basic, using fundamental concepts you will use on day 1 like simple loops. Sometimes they opt for the computer science route, and ask you to implement classic algorithms, maybe a sorting algorithm like bubble sort. Sometimes I have been asked to create a structure like a linked list, or a Directed Acyclic Graph.

You could specifically study these typical questions and then get past the code part of the interview process – even though in a real job you would struggle when posed with various real-world problems. There are plenty of websites that sell training courses that target these algorithms because they are so widely used in the hiring process.

So in the worst case, you will be writing code with a pen, with no resources to help you, under pressure from people watching and judging you.

Yet, when you are employed, you are using an IDE like Visual Studio on a PC, have more time to come up with a good implementation, and can use many internet resources to help you. You will need a good knowledge of the existing codebase, and be utilising 3rd party libraries.

You need to be able to communicate effectively with team members, use Google/Stack Overflow to find solutions/answers. I think it’s important to be able to do code reviews, and show debugging skills, but this is never tested as far as I’ve seen.

In a high-pressure interview, you don’t get a representation of how the person is day to day. I tend to panic in an interview, but am completely relaxed in my job. Even when there is a tight deadline, it still doesn’t faze me as much as an interview situation. So I’d say you can’t even reliably test “ability to handle pressure”.

There was one time we have used this typical interview approach for internal candidates. What’s the point giving a programming test to a software engineer that’s currently employed at your company? It makes sense to give this test to someone moving from another department. I got denied a Senior promotion using this method, yet most of my team members would have vouched that I was among the best in the team. Yet, underperforming Developers got promoted using this process. I’ve written many stories about them here (Colin, and Derek).

I’m not sure what the best way of judging developers, but I would probably go for a programming test using a laptop while allowing use of the internet (or just the interviewer’s knowledge). The test would involve writing some new code, but building upon some existing code which has a bug or two that the candidate is required to debug and fix. The final part of my test would be to review a selection of code changes to see how they handle Code Reviews. This could take a few hours, so I’d only include a few standard questions.

Currently, it’s a failed system if someone can be an excellent programmer, demonstrated by a comprehensive Github profile, yet fail an interview because they couldn’t come up with an optimal solution for some problem while being surrounded by a panel of intimidating interviewers.

Terrible Developers

Last week, I was reminiscing to myself about the developer that changed a random line of code which clearly wouldn’t have fixed the bug he was working on. It was also the same developer that repeatedly checked in “fixes” in an attempt to fix the build: Using the Build Server to test your code.

I said to my Apprentice, “how do you get into that mindset: where you write code, don’t even check it works then send it to your team to review?” but also “what happens if they did approve it and you are then embarassed when the Software Testers tell you it doesn’t work?“. Or even worse, “what happens if your bad code somehow went live?“

I wasn’t sure if I’d see something like that again, but it seems like we have hired some terrible developers in recent times.

Today, I was having a nosey at Pull Requests (aka Code Reviews) and saw some changes that seemed like the developer hadn’t even built the changes, therefore didn’t run their own unit tests they wrote, or done any kind of manual testing.

When you create a Pull Request, it triggers off an integration build. Then you can only complete your request if you have a successful build, and your team members have approved the change.

First of all, the build was failing, and it was a simple syntax error which Visual Studio would have highlighted, and definitely would have been brought to their attention if they clicked the Build button.

Looking at the code though, the first thing that I thought was funny is that they had a Code Analysis error. When you get these errors, most of the time you have to fix the problem it is highlighting. In the case that Code Analysis is wrong and you are smarter than it, you can add a Suppression. To make it clear why it is suppressed, you can add a Justification parameter and add your own explanation to it. To force people to do this, we have added a Custom Rule “SuppressionsMustBeJustifiedRule“. But the sneaky developer went and suppressed that!

[System.Diagnostics.CodeAnalysis.SuppressMessage("Custom.Maintainability", "CM3000:SuppressionsMustBeJustifiedRule")]
		[System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Reliability", "CA2000:Dispose objects before losing scope")]

I then looked at their unit tests.

bool isValid = validator.IsValid(input);
Assert.AreEqual("True", isValid);

I was convinced that would give an error and it certainly does.

Assert.AreEqual failed. Expected:<True (System.String)>. Actual:<True (System.Boolean)>.

Comparing the wrong datatypes. A Boolean is a true or false value but it cannot be compared to a String (text) representation of it (“True” or “False”). What they actually need is simply:

Assert.IsTrue(isValid);

If isValid is true, then the Assert passes. If isValid is set to false, then the test fails.

Then the next set of tests were like this:

string successMessage = string.Empty;
List<string> errors = validator.Validate();
if (errors.Count() != 0)
    successMessage = string.Empty;

Assert.AreEqual(string.Empty, successMessage);

So Validate returns 0 or more errors. If there are 0 errors then the test passes because successMessage was initialised to string.Empty and we are comparing it to string.Empty. If there are 1 or more errors, then we explicitly set successMessage to string.Empty (which hasn’t actually done anything because it was already initialised to string.Empty), then we compare it to string.Empty and the test passes. So no matter what Validate does, the test will always pass.

What an absolute waste of time.

I also said to my Apprentice that it is perfectly fine to have a go and writing some code but failing. Then you can say “here is what I have wrote, it doesn’t build but I don’t know why, can you help me?”. Then I can go through it, give him some advice, and together we come up with a good solution.

The worst thing you can do is give up, but then try and get the crap code checked into the codebase.

Configuration Switches

Recently, we were running into Out Of Memory issues with our software. A developer had identified that a feature which launched an embedded browser was using up quite a bit of memory, and we could move it into a separate process which would have its own memory allocation.

We followed his recommendation, so we moved the browser into a separate process and released this software (which I will denote “V1”). This caused an issue because the dll wasn’t built with the correct settings. We needed a quick fix due to the number of complaints from our users. It would be easy to fix, but due to the Testers stating it would take a few days to test it again, the managers told us to simply revert it and give the users the memory issues again (so this is “V2”).

We then fixed it, but since we had more time, we decided to implement a configuration switch so that if it went wrong, we could just disable it without having to release a new version. I made a small refactoring to get the configuration switch working, but I made a small mistake in the constructor which caused a crash in one of the places where the browser is launched. A Tester had found it late in his testing. I came up with a fix, but then we got called into a meeting to discuss what we needed to do. Unfortunately, my new fix would require a lot of the testing to be redone. The “refactoring” I did was brought up for discussion, and an experienced developer said that my way of doing it wasn’t the way he imagined. All the managers on the call trusted his judgement and felt I had gone a bit overboard, so they insisted I redo it.

So I had another look and couldn’t see how I could possibly do it without refactoring at least slightly. I did the best I could which I’d say was actually ~90% identical, apart from it was clearly worse from a code-design perspective. I showed it to the experienced developer and he said that was how he imagined it. I was baffled, but this is what the managers asked for. The release got delayed a week because the tester had to retest everything. So in the end, we had just wasted days of time to make the code worse. Brilliant. If we had gone with my original fix, it would have taken the same amount of time, but the code would be better.

Additionally, we did highlight we couldn’t test all the third-party suppliers we integrate with, so we had “low confidence”… or there’s some uncertainty at least. However, the Directors got involved and they wanted it out. So out goes “V3”.

There was a problem with just one of the third-party suppliers, but for some reason, Support left the feature enabled for several hours, when they could have reverted it with my Config Switch. This led to many complaints (yet again), and therefore panic from the management. When it came to disabling it, despite being able to disable it for particular users, they turned it off for large groups.

We rollout our changes in phases, so the Software Delivery managers wanted me to rollback the changes once more before releasing to the next group of users. I asked why we couldn’t just use the Configuration Switch, and the response I got was “we don’t trust Deployment to turn the feature off. What if they miss some users?”

Well, when those users complain, you just switch the Configuration Switch to “off”. If we rollback again, then we are back to square one; where users can encounter the memory issue.

What is the point in coding a Configuration Switch if they won’t use it? I did point out the way the Configuration Tool works is that you could set the configuration ahead of time (the previous software version will just ignore the extra config), then when the users get the new version, then the updated version would use the configuration file as intended. So with a bit of persuasion, that’s the option they went for. However, they turned it off for every user, even if it wouldn’t have caused problems for them.

When will they turn it back on?

Conclusion

It was actually a good idea to use a Configuration Switch. If the feature doesn’t work properly, you can quickly revert to the old way (well assuming your new changes don’t unintentionally break the existing feature). Obviously, you need to trust the Deployment team to actually use it correctly.

Colin went with a Configuration Switch for his recent project. How did he get on?

“The bug can’t be introduced by our project because it is switched off on live”.
5 mins later…
“This is definitely code that we changed”
Colin

Final Inspiration To Create This Blog

I noticed a folder in Outlook called Conversation History that has a log of all my conversations from when we used Skype. It’s a proper treasure trove of banter and funny stories. I’ll definitely be posting some of these conversations in the future.

I found this conversation pretty interesting. It’s from 6th February 2019. I checked the date when I started this blog. 6th February 2019.

The Skype conversation starts off with me pasting in comments from a Code Review. Colin had fixed a minor issue, but hadn’t added a new Unit Test for this scenario. I had flagged him up on it.

I was ranting to a colleague about Colin’s response. Colin had thought I was asking if the existing unit tests have been run, rather than me asking him to write new tests for the new functionality.

Me 13:22:

         Me
         unit tests?
         Colin
         Not failing
 
 
oh that's ok then. Just fix a bug and don't cover the missing scenario
WHY DO I WORK HERE?

Colleague 13:22:
Why would you not write one??

Me 13:22:
it may fail if you write one

Colleague 13:23:
Lol
 
Me 13:27:
I might write a book on my programming experiences

Colleague 13:28:
Lol, I'm sure it'd be a bestseller 😛

I think I did consider the idea of starting a blog because I thought I had good stories to tell, and was ranting about stupid things my colleagues did. However, I wasn’t 100% convinced it was a good idea. It seems like my colleagues’ reply was the final motivation for writing about my experiences as a software developer. 2 years on, and I am still enjoying ranting, and feel I have plenty more stories to share.

Shelving, failed restart, then restarting a project

When we entered lockdown, there was a small project that was identified as urgent, and very helpful to our users due to the current situation. Originally, they estimated a simple change. So we make a change to one file. When testing it, we realise it didn’t send the information in the outbound messages to a third party. So we made further changes which were a few day’s work.

We then had a meeting with a few different types of managers. They wanted to know about our progress and they wanted estimates to finish the project. I thought it would only take a few weeks to test. However the Tester said it would take 3 months which I think he was just being extreme to cover his back. He did explain it was more complex than I had thought, but still – it was clearly over exaggerated. The Managers didn’t like the idea of having a Tester tied up for that long, so the project went “on hold”.

Months later, I was invited to a meeting to restart the project. A Project Manager was ranting that there was a financial incentive to get the feature out by the end of the year (2020), but if we deliver it late, then we miss the bonus. Even if we restarted straight away, we had left it too late – there was no way the testing could get done, and deploy in time to meet such a deadline.

The Tester stressed that my solution is just a prototype and needs to be reworked. In reality, it was fine as far as I was aware, but he was just buying extra time if we needed it. It was the Testing side of things that needed the focus. We needed to test these extra configurations, but a prerequisite was that we needed to understand how they were set-up.

I couldn’t really do much work until the Tester had done this extra testing to see if my solution covers all the different configurations he had come up with. However, the Tester was busy with some other work so he couldn’t do that for a few weeks. A few weeks later, a Product Manager messages me to ask when the project started. I delivered the bad news: “It hasn’t”.

A few more weeks go by, and we have a meeting with a new Project Manager. So we discussed the story so far with him. It was also announced that the Tester (who has all the knowledge about this project) would only be partially available – so needs to pass on his knowledge to another Tester.

Another week or so goes by and another meeting was arranged. We have a new Project Manager.

Ridiculous.

She starts making all kinds of demands about having all the usual Agile process. (User Stories with estimates etc). However, it’s a weird project because we have basically done the development and we just need to test. All this process seemed a bit overkill to us.

We had another “Project Kick-Off” meeting, and the Tester asked the Software Architect about setting up all these different configurations. The Architect then said the Tester had misunderstood and there was actually only 1 configuration.

This meant the testing time had been drastically slashed – you know; the exact reason why the project was delayed in the first place. So all these delays, extra meetings talking about the delay, all the meetings to rearrange the project; none of them actually needed to happen. We could have just completed the project when it was first assigned, additionally collecting that financial bonus.

Estimates Meetings

There’s a meeting that (I think) happens every week, where projects/enhancements are discussed and estimated. I don’t think there is enough time to really discuss them in great detail, and the people in the meeting don’t really care because they won’t actually be developing and testing them.

The thing is, it’s quite hard to judge how long something will take even when you have a decent understanding of the requirements, because you don’t know what the current state of the codebase is until you really start to dig into it. Also, you will uncover multiple problems and come across things you never considered earlier.

I think the key thing to remember is that ‘estimates’ aren’t supposed to be exact and are only based on the knowledge you currently have, plus additional time for contingency.

Even considering that, I think most people struggle to come up with estimates – even people that are regulars to the meeting and should be experienced at it.

One day, I received a message from my manager asking me to join one of these meetings. The meeting had been going for 10 minutes or so.

I join the call, and my manager tells the Host to re-explain. I felt awkward, he probably had done a great 10 minute explanation, and then they somehow decided they need my advice. So the Host reexplains. I ask a few questions, in particular about some previous functionality that had apparently been rolled back. I wanted to know why it was rolled back rather than fixed, because that would be key in coming up with an estimate.

My manager decides that we need the previous Product Owner on the call. She joins the call, and my manager asks the Host to re-explain. This is definitely awkward now. You can tell the Host is so frustrated, and he audibly sighs before explaining for the third time.

Now the group should estimate collectively, but everyone seems to want me to estimate it by myself. Why does everyone think this is a hard one to estimate? I end up being vague and saying it was 1-3 weeks. The thing is, they usually want the estimates to the nearest 2 week period, so 4 weeks is a fine estimate. I try to push the others to suggest their own estimates. The group decides it is too hard to estimate so the Host needs to come to a future meeting with more information. He must be fuming.

I get invited to next week’s meeting. There’s 2 projects to estimate – this time brought by a different product manager. This new Host says the first project was estimated a year ago, then put on hold. It was given 16 Weeks at a “high confidence”, however, there’s no notes to explain how they came up with that figure. But it is “high confidence”, so unless we know of any complications that have happened over the year, maybe we could stick with that?

Judging by the small amount of notes and screenshot, it looked like a few day’s work to me. One person says there’s some “cross-account functionality which is against the current architecture”. So now we are all scared. One manager states: “There’s too many unknowns, so let’s come back to it”.

So the Host moves onto the next project. It’s quite complicated and requires a good 10 minutes of explanation. When she got near the end, I thought “I hope we don’t estimate it; it will be a right laugh.” When she concludes her amazing speech, we decide “we need to break it down – it’s too big”.

So that’s 2 hours of meetings to estimate 3 projects and we didn’t estimate any of them. Good work team!

Bad Quality Project

Recap

The Code Analysis report gives metrics on code quality, and we want to improve the overall quality of our code over time. We put great importance on the Code Analysis report even though we haven’t done anything to address the issues. It’s just that certain managers keep hyping up how important it is.

New Project

An important project is going into the Main branch which will be released next month. I was asked to review the code. I was originally told the review would be sent by the end of the day, but it was delayed a day. I proactively found their code branch and saw it was out of date by a few months, which isn’t a good sign. (They should be merging Main into their project branch to minimise code conflicts).

So after they finally updated it to the latest version and sent the review, a manager said they “really need to get the project reviewed and approved by 5pm so they can start the regression testing tomorrow”.

I jestingly asked if the expectation is that ‘I click the “Approve” button without looking at the code’ – if I criticised their code in any way, then they would miss the deadline since they would have to make the changes and retest those features. It was true though, the deadline was about 3 hours time.

Since we are more ethical than that, a few of us ripped it apart. Initially, we ended up with around 100 comments which I think is the largest I’ve seen on a review. The next day, we added even more to get it up to around 130.

If they really wanted to cut corners, then it’s up to the managers to decide whether they want to skip the review and check it in anyway.

I thought the pressure they were putting on the reviewers was unfair. It wasn’t just that initial message (“need to get the project reviewed and approved by 5pm”), but they kept on sending direct messages to each of us asking when we will be finished because we are pushing time.

Code Critique

Instead of moving some old code to a new location, and refactoring it so it is reusable with the new features (utilising C#’s object-oriented style (base and derived classes), then fixing up the existing issues to meet our coding standards)… they decided to copy and paste it instead.

So now we have some old, bad code; and some new, bad code. When the Code Analysis report runs, it is going to flag up issues in both files, and if it successfully identifies the duplication, we will have loads of Code Duplication errors too. Brilliant.

I expressed my concern to the team’s manager and he gave me a response along the lines of “we were a bit pushed for time, so decided to take the easy route”.

On the review, I questioned some of the messages we were displaying to the user, and the response I got was “this is an existing message”. Well, fair enough to a point, but why didn’t anyone question if it should be changed. You are revamping that area of the system, why don’t you improve the quality and user experience whilst you are there? The project has enough testers allocated to it, and they will be testing these changes in detail. It’s a great opportunity to rewrite it.

There were several files where their response was “actually, this file isn’t used, so I’m deleting it”. I’m not sure how that can happen with several files. Why only realise now?

Closing Thoughts

After all those discussions about how our team is supposed to have Quality as our main focus, then we proceed to make a mess of things!

It would be nice to have some consistency. If I check in some code that shows up on the report, then I get an email from someone. It doesn’t matter if I have reduced the problem count by 50, but added 1 new problem – they make out it is a problem.

Why is someone manually emailing about what a report shows, rather than having it as an automated check as part of the review? Maybe it’s a licencing issue. If they were that serious about this report then they would pay for it and enforce it properly.

There’s been a few times where projects were supposed to be merged in, and the people doing the code review didn’t like the code. If you are doing a project, maybe get an expert to review your code earlier in the project. That way, you don’t get loads of issues to fix on the day you are supposed to merge it.