Haven’t done a weeks work

I’m currently finishing off a project where we have been assigned a new Project Manager. She hasn’t made a great impression so far.

The Testers haven’t been available over the week, but personally, I did complete the development on 3 items that I’d estimated to be 8 days work, so really that’s 1.5 working weeks of work. So in my mind I was ahead of schedule by half a week.

The Testing hadn’t been done, so we hadn’t fully completed the items, so technically, we get 0 points there. However, I was ahead from my side.

Then in our project meeting (which the Testers also couldn’t attend), the Project Manager stated that she was very disappointed because “we haven’t done a week’s worth of work”.

I told the Testers what she said and they were outraged because they felt “it wasn’t her place to comment”.

A few days later, she sends me a message like:

“could you please quickly pop intot eh knban BOARD AND MAKE SURE YOU HAV PU SEOM NUMBER OF DAYS AGAINST EACH OF YOUT ITEM SO I CAN SEE HOW LONG SOMETHING TOOK ETC”
Project Manager

Did she type that without looking at the screen? So bizarre.

Gibbon Testing

In my first programming job, I worked for a small company (under 10 employees in total). We had no Software Testers, and we definitely didn’t have any testing process. I don’t recall any automated tests either; I certainly didn’t know how to write them at the time (not even Unit tests).

When I finished my work, I informed the Senior developer, and I would upload the software to a touch-screen Terminal. He would casually play about with my new features. If he was happy, then the CEO would do similar tests; just casually explore and verify I had done what I claimed. Once he seemed happy, he did his final test: “The Gibbon Test”.

You could say this is some kind of performance testing, and also testing out multiple features in a short amount of time. What did the testing involve? Well, just frantically bashing on the screen.

I’m not sure how serious he took the testing. I mean, obviously it was a joke and we all laughed watching him do it. However, on reflection, I think it is actually a good idea – definitely a good one to do last after you perform all your serious tests.

With certain applications, the user could be frustrated and hit the screen randomly. Your program should be resilient to such abuse. I think a good example would be some kind of gambling game. When the user loses their money and hits the screen in frustration – the application shouldn’t crash, or take ages to respond. It should be ready for the next person to use.

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.

Stupid meeting times

I had a 30 minute meeting starting at 4:30 which overran by about 30 minutes – so it actually finished at 5:30. It’s a problem when I finish at 5, but that’s work I suppose.

The next day, I logged in 5 minutes late at 9:05. I received a message from the Tester on my team:

“are you joining this meeting?”

“What meeting?”

So I opened my emails and saw a request for a 9am meeting which was sent at 5:45pm last night. Ridiculous.

We have this concept of flexible working so the “core hours” are 10-4. This is because you can basically work 8-4, 9-5, or 10-6. Therefore meetings can only really be scheduled between 10-4 if you want everyone to turn up. A 9am meeting isn’t bad for me, but it is when you haven’t had the chance to even acknowledge the invite, and haven’t had a chance to even consider or act upon what was discussed the day before.

How To Make Your Team Hate You #2

I was thinking about the colleagues I’ve legitimately despised (and it’s not just my opinion), and most of them have something in common: they have either been promoted, or told they will get promoted if they prove themselves. So here is story number 2.

We were in a newly formed team, and Rob was a newly promoted Test Manager. As developers, we were planning on tidying up the code base, formatting the code consistently, and removing unused code.

There wasn’t any real testing to do, given the code was unused, but Rob insisted we spend time investigating how to test the code.

It didn’t make sense – how can you test some code that isn’t used? Unless you prove it somehow is used, of course. But if the developer could tell the tester how to prove it is used, then the developer would know it is used, and wouldn’t remove it.

For the actual, real, development work, Rob demanded that we come up with a full test plan for every planned piece of work before we are allowed to make any code changes.

The thing is, even though I know the overall aim and could explain some test scenarios up front, I will always suggest more tests after I make the code changes. After I have made the changes, I am familiar with other areas of the system it impacted, or extra changes I made to refactor the code. So it only would be a temporary plan anyway.

Once we made that point, Rob then said we should analyse the code, plan out what code changes we would make, including refactoring, and document them. When all items are documented, we could then start work.

Who agreed in the team? No one. Not even other testers. Yet, he then runs off to higher ranking managers and persuades them that it is a good idea. I think they were just good friends with him, so they backed him.

We ended up spending ages working out what we were gonna change, but then not actually do it; because we had to plan every item first.

When the time came to actually implementing our plan, you then had to spend time re-familiarising with the solution and then verifying if the proposed solution was actually accurate. The person that did the planning may not be the person to actually implement it.

We ended up being 2 months into the project and not a single line of code was changed. When we started doing the work, the “familiarising” process just annoyed people. From the start, we had stated that the entire process was dum, we were annoyed at the extended planning time, then the actual development stage just reinforced how dumb the entire thing was.

I don’t know if anything happened behind the scenes, but Rob was moved off our team at this point, and it felt like a huge weight off our shoulders.

I don’t know what Rob aimed to achieve with his idea. I think he thought it was a process that enforced quality, but he was unanimously told it was a bad idea, but yet fought to get it implemented. Surely if the team is fighting against it, then dictating that they implement it is just going to cause so much friction – that your position is going to be untenable. And it was.

The lesson here is that if you do get promoted, make sure it doesn’t go to your head. Yeah, you have to manage people, but having a new fancy job title doesn’t mean you have to go wild. You are working with people. You are still working with your old colleagues. Treat them with respect and be more understanding. I think a lot of managers gain respect by being nice and leading by example.

More work

A couple of months ago, I did tell my manager that we don’t have enough developers in the team. I end up with a bit of backlog of things to do, but I also need to dedicate time to train up my Apprentice. Quite often, we end up with conversations like this:

Manager: “Hey, what are you working on?”

Me: “Such a fix, after that, I need to return to the last bit of work I parked.”

Manager: “I have another task for you.”

What made me laugh is that the last time this conversation occurred: halfway through the day, he then tags me in a conversation about a bug and he says “this is tomorrow’s work for you”. So he gave me 2 more tasks to do that week.

I think this proves we don’t have enough developers. Colin’s been “preparing” for a project for a few weeks, Beavis has been making more excuses why he can’t work, Rob has been confused about his bug fix for weeks.

If we worked at pace (reference to a previous blog), then developers should be free to pick up this work.

Mid Year Review 2020

Intro

I’m not sure if the “end of year” coincides with the tax year, or if this “mid year” should have been a few months back, but the organisation of our performance reviews has been poor this year.

I think we were supposed to agree on some objectives back in January or something, which got delayed, I think this was mainly due to managers having to decide which crazy criteria we are judged against this time. I have ranted about different ways of evaluating performance, but they usually seem unfair and favour those who love to exaggerate or are a bit dishonest; which isn’t who you want to give pay rises and promotions to.

Anyway, the mid year review was booked in and I pointed out to my line manager that I have no objectives and haven’t prepared anything. Then he said “don’t worry, I’m just gonna free-style it”.

So much for being fair! In previous years we were told the strict process and consistency across the departments was for fairness. Now we have regressed for a pure free-for-all.

However, I’m not complaining because I hate the majority of reviews. I think you do have to be purely subjective when it comes to analysing developers, and I think you have no choice but to judge how well they fit in the team, which the manager should have awareness of. So I have more chance of finally being promoted under this unorganised style.

The Review

So my manager Chris, begins the meeting by explaining that he has got some notes on his own opinions:

“you’re the strongest developer in the team, or you are up there with the best”
Chris

and he has also asked for feedback from my colleagues.

“the biggest problem with working with him, is that he is too good”
Anonymous

“why isn’t he a senior yet?”
Colin

I know that one because Colin had personally called me last week and told me he had questioned it with Chris. No idea why Colin is lobbying for my promotion.

I’m good friends with one of the Software Architects, and he has also been trying to influence Chris on my behalf. So I have 2 people protesting about it which is funny.

‘The promotion is finally here’, I thought. Then Chris starts saying that there’s been a bit of negative feedback too, and it’s my communication.

He said that I’m too cynical and sometimes put a downer on the outlook of the project. I wasn’t sure what he meant at first, but then I later realised that as a joke, when the slightest thing has gone wrong, I do say things like “the project is gonna be cancelled!”. Are people actually taking that seriously? It’s just over-dramatic comedy. Instead of Chris asking “how are your projects doing?”, he always asks “are there any projects on fire?” How is that any different?

I do wonder who doesn’t like my humour, since when I am on calls and say things like that, people in the team do laugh. Given that I write it on a lot of Slack posts, surely people understand it’s just a recurring joke; like a comedy sketch show. There’s plenty of witty humour too, not just recurring phrases. I bet it is Becky or someone with a similar personality because she just seems a bit out of touch with technology, and is a bit too serious. She also asks stupid things so I can be quite snappy in my responses on Slack, so out of everyone in the team, I bet her opinion of me is the lowest. At least I answer her questions, most people don’t even attempt to help.

Chris did say to maybe not joke around so much, apart from when I’m with him because he loves my humour.

Chris also started saying he needs even more evidence of my Senior qualities to take to Senior Management to persuade them of my promotion. Therefore I need to accept more responsibility and take the lead on projects.

I think I argued my case really well. Firstly, I said “how can I lead when we have loads of Seniors in the team?” They should be leading because it is their job to do so. The fact that not many show much leadership anyway means they are underperforming, and also I am held to different criteria. It’s also Chris’ job to decide who works on a particular project. So if I’m never the most senior in the team, then I can’t lead. That’s not my fault.

I also stated that I have been given these challenges like mentoring and I do show senior ability by doing all the Code Reviews, then nothing comes from it, not even a wage rise. He kept on saying he needs evidence to convince the senior management, but I said that he has enough; he had said he regards me as one of the best developers in the team, and realises I was essential in dealing with all the recent urgent fixes that everyone shied away from. He can see that I’m one of the few developers that engages with the conversations on Slack/Teams. What is everyone else doing? Either doing their own work and they don’t care about the rest of the team, or they are simply chilling out.

He did ask why I thought I hadn’t been promoted in the past but others have been. I said others are probably a bit more firm in their demands and threaten to quit if they don’t get what they want, whereas I just get on with things. Also, the way we attempt to measure developer’s performance is just nonsense.

He did say to improve my communication, I need to show more authority and be more firm in my views. So I asked him for a payrise, otherwise I may have to quit!

Result?

It was funny how he said my humour was perceived to be a negative aspect, but I was running the Performance Review like a comedy show. I can’t help myself chipping in the humour. Although there is truth in my demand. If someone joined the company in my role, you can guarantee they would be on equal pay or higher, because I’m somehow still bottom of the salary band. He did promise to look into that.

He did conclude he would sort out my promotion, but when I pressed him on timescales, he refused to comment. No doubt I’ll have to wait another year or something daft.

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.