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.

Shoes

Years ago, a manager had accidentally posted a link in the Discussion section of a Bug report. So they had a comment discussing a possible root cause, but then all of a sudden, had a link to a shoe website.

It looks like it may be a side effect of “Bug 512: Unable to edit a document”. It’s difficult https://www.startriteshoes.com/ to tell from the video though.

We thought it was hilarious, especially because (for whatever reason) you couldn’t edit or delete comments. Even if they realised their mistake, it is permanently on the system, unless they told an admin to specifically delete it. It’s become a bit of an inside joke, and we often reminisce about it.

It was also very pleasing when we once got an email on the topic of shoes:

*** On Behalf of Security ***
A package arrived this morning without a name/surname so it has been opened.
It appears to be a personal order for a pair of Disney branded shoes – unless this is to form part of the company dress code?
Package will be with Security over in the main building – ready for collection.

I love how security have thrown in some banter. He probably got annoyed about the amount of personal deliveries he had to sign for.

Stevie Martin

Stevie is hilarious. Absolute perfect sketches mocking problems with modern technology.

Not A Robot

Mocking different types of Captcha

Printing

Ink cartridges, paper jams…why are printers so bad?

Passwords

Stupid password restrictions that you won’t remember

Purchasing Online

Marketing emails and recommending items you already bought.

Communication Breakdown – Reports

All our server calls are logged in a monitoring database along with their execution time. We generate reports in order to spot any negative trends and identify where we could make efficiencies. Additionally, we need the server calls to be under 2 seconds to meet our contractual obligations.

Ryan got told to update the performance monitoring because some of the calls had generic names like “Add” and no one knew which server call it actually was because there were more than one feature with the same name. After his changes, all the logged server calls have more verbose names to easily identify where the code is e.g. “Configuration.Users.Add”. However, no one told the people who generate the reports that they need to modify their report-generating program to take into account the new format.

So when the new update went live, the reports were broken because they are searching for the wrong method names.

There was a “Major Incident” call with managers and support staff who all had no idea what was going on. I invited Ryan to the call to explain the change. Ryan pointed out “this should be in the release notes”. However, when they checked, all they stated was “Performance Monitoring should be more traceable” which is not only vague but doesn’t highlight an action for a team to take.

There should have been some explicit communication between the teams, and the improvement agreed upon. It sounds like the feature was requested, but the team hadn’t known a developer was working on it and would have it ready for the upcoming release. Additionally, if there was some communication when the development started, maybe there were other problems that could have been fixed alongside this change for increased benefit.

Praise For Slow Response

Sometimes, I think managers praise projects no matter if they release early, on-time or late. Yesterday, a manager posted this:

“I wanted to call out the success of the NFF Project where we fixed the broken NFF Processor Tool which was not working in live since September 2020. This fix went live successfully on May 4th, 2021.”

Fast response

Why have we left it ~8 months? Surely this deserves criticism and not praise?

Requesting Help – But Not Providing Enough Info

Becky is a Software Tester with maybe 15 years testing experience, so you think she’d know what she is doing.

When I was a Tester, I quickly learned what the developers wanted in order to help you. The Message and Stack Trace is mandatory if the software crashed, but it’s always great if you can explain what you were trying to do to “set the scene”:

What you expected to happen,
and what actually happened.

Then, if possible, state specific steps to consistently recreate the issue. This is what Developers need to fix a bug, but the same information is great if you want help after failing to configure a server/feature etc.

In this situation, Becky had what sounded like a straight-forward task, and under normal circumstances, you could just log in to the software, fill in a few fields and click save.

She posts on Slack for help, and states she thought this task would be simple but it’s “not the case”. Then says with “Alan’s help, I’ve changed a config file”, and she was trying to use a configuration program but was “unable to connect”.

I’m reading her message and thinking “why has she changed this config file?”, and “what has the connection error got to do with anything else she said in the message?”. She should be able to do all this using our software.

So I message Alan to translate what she said. He did explain it wasn’t that simple, and so they were doing this configuration an alternative way. He said the current problem was just connecting to the server, and he had told her to log a ticket with the Networks team. He said after that, he would carry on helping her.

So I reply to her message on Slack, stating that Alan is still helping her.

She then says that she “knows there is knowledge within the team and didn’t want to take up any more of Alan’s time”.

I thought she was just wasting other people’s time by trying to get other people unnecessarily involved. Alan had helped until this blocking issue occurred; which Becky needed to get the Network’s team to sort out. There’s no point wasting other people’s time.

Since I had already invested some time into it, I decided to ask her some questions. I wanted to know the IP address of the server she was having trouble with, the IP address of the system she was initially configuring, and a database ID so I could actually see if she had the data in the correct tables.

She only answered 1 of my questions, and her response was a slight rephrasing of the thing I questioned. So she wants help, but won’t give me the info in order to actually help. At no point did she say that Alan had instructed her to log a ticket, so she wasn’t even following what Alan told her.

I find that there are a lot of Software Testers that fail to give you enough information to do your job. Somehow they think you can magically work out what they intended to do, and work out what the problem is with barely any information.