Regrettably Paused

About a year ago, there was one employee that posted an angry rant about the lack of communication between managers and development staff when big changes were coming. The managers actually responded positively and said they will work on it in future. Well, it’s happened again.

It seems she was working in a subteam on a project, and her subteam was never told their project was on-hold. She heard the rumours/news from someone else, and posted this rant before the managers fully declared it to the department:

If a project is “regrettably paused” or abandoned in future, please would you consider announcing this news in the form of a department-wide meeting, inviting all those who were involved with it?
This gives people the opportunity to ask questions or make comments, much like you would if a doctor was giving you bad news.
Developer on a cancelled project

We have had a tendency to cancel projects, big or small over the last year. Some have involved my work where I had finished development – and it only needed to be signed off by Testing.

Another manager made an unrelated post about them sorting out the project plans and bug fixes. They said there were “300 pieces of work in various stages of the software delivery lifecycle. We’ve decided to continue 189 items, reject 35, and move 76 back to the Backlog for further review.” I don’t know the details of these changes, but I really hope they haven’t cancelled loads of inflight work. It’s just demoralising to have your work cancelled, and a waste of time when it wouldn’t be much work to complete it and get the new features out to users.

Maybe there’s nothing you can do about it. If managers insist we want to follow a new process, shuffle the teams about, then the current work basically needs to be abandoned otherwise the new teams cannot form.

Working On The Wrong Project

This post, How do I tell my boss I’ve accidentally been working halftime on the wrong project for the past year?, appeared on Stack Exchanges Hot Network Questions, and it is an interesting story. Is it true though? It’s definitely hard to believe.

Even though the process and management where I work is a bit slack sometimes, I just can’t imagine this scenario could possibly happen. There’s too many failures that have to happen for it to get to that stage.

A tester starts a new remote-based job and is assigned to 2 projects. 11 months later, he realises that he was only supposed to be assigned to 1 project, and was wrongly invited to the initial meeting because he shares the same name as another staff member.

When he has one-to-one meetings with his manager, he has somehow talked about work in a way that the manager didn’t realise he was working on the wrong project.

He eventually meets his team in person, and it seems some people knew the other staff member with the same name, but not enough to realise this person wasn’t the same.

I have no idea how this can actually happen.

There’s definitely going to be situations when you realise two people have the same name in your company, and especially if it is you that shares the same name. Someone emailing you by mistake; receiving an email from the other person; seeing a post on whatever chat app they use eg Slack/Teams.

Surely you have daily stand-up meetings where you talk to your team. Someone would surely realise you aren’t the person they expect, unless they all accepted it was a different person, but then they wouldn’t act like you were the other person when you physically met up.

If they really did believe it was their original colleague on the project, and there were no meetings, surely one of the team members would have communicated to the other person to ask them how they are getting on.

If the organisation only assigned a Tester to 1 project, surely there would be a point where you say you were too busy with “the other project” and would be challenged. They must be assigned to a couple of projects as standard, but then that means this person should have been assigned to a third project. It makes me wonder what the other guy was doing. The original poster says they were “focusing on other work”. Probably chilling for a year then 😀

If you have to log your time, surely a manager would realise something isn’t right when they look at the overall figures, or just your own..

If this Tester was comfortable doing both these projects, doesn’t that indicate Testers are actually underutilised and are only working at 50% capacity? I do think Testers could easily get assigned more work but they always seem to claim they are really busy.

It’s a mystery.

The Changes #3 – Tech Stack

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. In Changes #2 I explain that Developers are also affected.

Our previous management decided our upcoming software would specifically use the cloud service AWS, whereas the new managers want a “cloud-agnostic” approach (work with all the clouds!). So they want us to have the possibility of using one, or a combination of: Azure, Google or AWS – although the emphasis seems to be moving to Microsoft’s Azure.

Currently, I don’t think there is much rationale for this. Everyone specifically learned how to use AWS, so will need some time to adapt to the differences. When people started learning about Cloud Technologies, the problem of “Vendor Tie-in” was raised and instantly dismissed by the previous management. It makes sense to ensure you have that flexibility, because if your provider increases their costs, then you can easily migrate if you had the architecture for it.

Another change is that they want every product to have their source code in GitHub. Maybe it does make sense to have all our products in the same place. The reason we have them scattered is mainly because our products were acquired by a series of acquisitions, so the original companies had chosen their own languages and technologies. However, our core, flagship product is already in Azure DevOps, and given that the main cloud provider is going to be Azure, surely it makes sense to keep it all in one place?

These changes to jobs, processes and technologies seem to have solely been decided by the CTO and Head Of Development. I feel like they haven’t discussed these ideas with the Development staff at all. I’m intrigued by what other arbitrary changes will be forced on us. With any change, I think you always have to ask yourself “what is the problem we are trying to solve?”. If you can’t explain the problem, then it shows you are making changes just for the sake of it.

Recently, I have been reading Sir Alex Ferguson’s “Leading” book and came across a great quote:

“There is no point suddenly changing routines that players are comfortable with. It is counterproductive, saps morale and immediately provokes players to question the new man’s motives. A leader who arrives in a new setting, or inherits a big role, needs to curb the impulse to display his manhood.”
Sir Alex Ferguson (ex Manchester United football manager)

I thought it was a very relevant and appropriate quote for this situation.

Development Department Objectives

About a year ago, the Head Of Development shared a list of development objectives that she was responsible for. Although each point sounds good, how do you even achieve these? and how is she held responsible for them if she succeeds or fails?

1 Reduction in Major Incidents

A Major Incident can simply be a bug that many users would see and was introduced in the most recent release. It could also be a high-severity bug; e.g. a feature is completely unusable, or if you could see someone else’s data.

You could have some kind of policy enforcement, like increasing automated tests coverage which you run on every release. It’s not going to catch everything though, but it’s a start. I think this objective is okay.

2 Reduction in Major Incidents fix time

How long does it take to fix a bug? Every bug is different. You need to recreate it, then come up with a fix, then test it. Sometimes the feature may partially depend on a 3rd party and you may need some complex set-up to get the feature working. Each of these aspects can take between a few hours and weeks. It’s out of your control.

What you can change is the time between the user encountering the issue, and it being assigned to a developer. I have found that sometimes issues are discussed on a Wednesday, then somehow get assigned to me at 3pm on a Friday and there’s discussions on who can work weekends for it to be deployed on Monday at the latest. Yeah, we can definitely improve that process, but the overall metrics are essentially just going to be based on luck.

3 Increase rollout pace

I’m not involved in the deployment process, but sometimes this is beyond our control anyway. Some of our customers will refuse updates, or request we delay patching them to when fewer users are using their system.

4 Reduction in issues

If it was so easy to not introduce issues, then surely we wouldn’t introduce them. Maybe some people think developers introduce issues on purpose to keep us in jobs! However, there’s plenty of new feature requests and improvements we could be doing, but we spend so much time fixing bugs. We would much rather be introducing new, cool features.

Again, you could improve processes like automation coverage, but it’s easier said than done. Even if developers write Unit Tests, we have Manual Testers verifying our changes, and sometimes other Automated Tests – bugs still get through.

You could reduce the chance of issues by making the releases smaller. Fewer changes mean lower risk of breaking anything. Not releasing at all means there will be zero new bugs. You could make this metric appear better, but by lowering the productivity in the department.

Conclusion

I actually don’t know if we achieved these. I wouldn’t have thought so, but the Head Of Development got some kind of promotion, and some award for her work. If we did succeed, it would be by pure chance. I don’t recall any kind of initiative or process change that made a difference.

Protected Time

We often find that managers will arrange meetings when everyone appears to be free, but they don’t consider if it is actually a good time. So they often arranged meetings during lunchtimes. After our Head Of Development announced that he wanted to ban the practice, many managers seemed to ignore this and carry on. It eventually got flagged to HR who then declared it was going to be a group-wide process, and we can no longer have meetings between 12-1.

I know many people who like to have their lunchtime at 1, but I guess they should adapt for convenience. I guess you cannot block meetings between 12-2 to cover all possibilities.

Our new CTO arranged an hour-long training session 12-1. It wasn’t that he wasn’t aware of the policy; he declared that he knew the policy – and was deliberately violating it.

“We have deliberately scheduled it within protected time as this is exactly what we should use our protected time for – a chance to learn and develop ourselves.”
CTO

I stated to a colleague:

“I thought the protected time was protected so we can actually eat… I’m currently developing myself with a sausage and egg sandwich”
Me

I don’t get why he thinks the protected lunchtime should be used for training. It was specifically to ban meetings during this time. If we had food ready, we could eat while listening. However, others may need to cook, want to go out for food, or like to eat with their family.

Name and Shame Emails

Don’t you hate it when you get an email stating that you haven’t followed a process correctly, but then everyone else that has also made the same mistake is listed in the “To” field of the email. So it’s basically “naming and shaming” everyone.

One particularly patronising work email I have received recently is the one where you haven’t submitted your timesheet. There’s massive screenshots of the website with red circles and arrows pointing at each button you need to click in order to submit it.

It’s so dumb because it only makes sense if you have NEVER submitted a timesheet: If you have submitted several weeks worth, then missed 1 week, why do you need step-by-step instructions of which buttons to click? You know what to do, all the email needs to say is that you have missed a week, and it should state the date that you missed.

However, out of the 3 times I have received such a patronising email, there was actually only 1 time where it was actually accurate. The other 2 occasions, I checked the timesheet and everything was showing as submitted. I can only assume what they did was prepare the email a few days prior to sending it. Then in the meantime, I had gone and filled it in. Either that, or maybe it was a bug in the software.

If you are basically going to criticise someone, at least you need to make sure it is accurate. Then it’s advisable not to make it known to everyone by sending mass mails.

On a related note, I received the following email today:

As you may be aware, all colleagues are required to complete the Data Security training annually.
Our reports show that your training is still outstanding.
The training needs to be completed by Friday 30 April at the very latest. A status report will be sent to the Directors on Wednesday 28 April.

I don’t recall seeing any previous email about it. Yes, it is supposed to be an annual thing, but surely I’m not supposed to create my own reminder – where is the autogenerated reminder? When I went to do the training, it was actually 1 year and 3 months since I did it last. So in my opinion, that’s their mistake but now I am receiving an email that tries to make me feel like it’s my fault. With only 8 working days to complete it, surely it’s possible there are some colleagues on annual leave during this time, in which case I’d imagine they will then have the Directors on their back.

Ironically, part of the training involved General Data Protection Regulation (GDPR). One of the examples of a failure was about sending emails with all the recipients in the “To” or “CC” field, rather than the “BCC”. It’s probably really relevant when sending external emails, rather than the internal email I received about the timesheet. Still, it made me smile, and I think the general principle applies that you shouldn’t receive unnecessary information about people.

“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.

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.

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!