Tag: Software Development

The Proxy

A new customer reported a particular feature was broken. This feature used a web browser (Chromium) to work.

A developer spent ages trying to work out what was going on and realised that the site had an invalid proxy script. The invalid script was causing a crash within Chromium, rendering this feature completely unusable.

Due to a typo in their proxy script, their proxy wasn’t blocking access as described by the script; it was basically “anything goes”.

The developer told them how to fix it, and we thought it would be case-closed. However, now that the proxy blocked access to websites as defined by their IT department, their employees started complaining.

Instead of the IT department:

  1. tweaking the rules, 
  2. Disabling the script completely
  3. or simply informing their staff that these sites were blocked according to their company policy

They decided to revert back to the original broken script. This obviously made our software break again. 

Really, it was a problem with Chromium, the software used in Google Chrome and now Microsoft Edge. Obviously, the workaround is to actually set a valid proxy script, but they decided to be awkward.

The Code Quality Merge

I get a pull request to approve from Colin:

Title: merge Main in to the code quality barnch
Description: merge Main in to the code qualiaty barnch

It’s somewhat ironic that it’s about quality, yet is riddled with typos. Also, why didn’t he just copy and paste the title and description?

Usually, you can just approve merges, there aren’t any new changes from the developer. They are just updating to the latest version. I have a quick peek and I notice that it doesn’t actually have the last set of changes that went into the Main branch.

So I left a comment;

“Isn’t this still 2 weeks out of date?”

The comment of shame

Nothing like quality.

Pair Programming With Beavis

Beavis is a software engineer that loves making excuses to avoid work. Beavis had a bug to fix in the same area that his previous fix was for. For his previous change he did ask: 

“It’s a fix for the current release, so not sure if it goes directly in, or we Dev test before-hand.”

When developers say things like this, I do wonder how and when they test their changes. Do they just change a few lines, and “throw it over the fence” to the testers? Why does it matter what release it is for? “Oh it is for an urgent release? I won’t test it then”.

I don’t think he manually tested it, or even understood the overall context of his changes, but he did eventually add some unit tests which were logical and I believed would prove his fix would work.

The problem is now he has a new bug fix to do, and he still doesn’t understand the context. I was free so I was asked to help him.

For this change, we specifically needed to use a Virtual Machine. We were supposed to set them up a month ago, and Beavis had, crazily, logged 20 hours against this work on his timesheet.

Me: “Have you set up your VM?”

Beavis: “No”

Me: “OK, well that is going to take you the full day. So download the required programs and check out our source code”

I didn’t really expect it to take the full day. Maybe half a day, with a bit more time if there were problems somehow. I wanted to get a head start looking at the code so I had a better chance of training him later. I also thought if I allow him a day, at least it will lower the chances he is going to start coming up with excuses.

I began to look into the problem whilst Beavis was setting up his VM. The next day, Beavis doesn’t show up. The next day, Beavis returned to work but said he was having network/proxy issues so could not download the required software – so was stuck.

It took me a lot longer than expected, but even allowing Beavis 2 extra days, he still didn’t get ready. So I did it all myself.

Testing and Developer Equality

I think it is possible to have an “us and them” kind of attitude between the developers and testers. You are supposed to work together to a common goal; deliver quality software. 

Since testers have the responsibility of making the final call if the work is good or not, and can send it back to the Developer, then there can be some resentment here. I have felt that a bit when I was a Tester, but it’s rare to witness events like that.

There was a time when it was announced that the Software Tester job title was changing to sound more important, and recently, there has been rumours that my employer is considering making Developers and Testers: “Engineers”. I don’t understand what a blanket term like that even achieves. Surely it is a nightmare for managers to sort out projects in the future. New managers may end up trying to put several Testers in a team together because all they see on a spreadsheet are several “Engineers”.

Surely it makes recruitment harder when you are advertising for “Engineers” and it isn’t clear what job you are applying for.

Some Testers can write code, and they will create Automated Test scripts, or some helpful application. Not all Testers can write code, or have even a slight interest in writing code.

I think it’s a case of managers trying to fix a problem that doesn’t even exist. There have been a few Testers that were vocal that they don’t want to be called Engineers. They are Testers and are proud of it. They feel that being called Engineers will come with the expectation that they have to be able to code and they don’t want that. I’m sure some Testers will be happy with the proposed change, but I think most people will agree it is a stupid change.

I do wonder who came up with the idea? Why change something if there isn’t a problem? What problem is this trying to address?

Merging for 3 days

There was a project in a code branch that needed merging in for the release. Colin volunteers to do it. I expected that it would take him half a day, depending on if there are conflicts to resolve which can be quite tricky.

3 days later, he sends it for review. A couple of developers reviewed it and left him 17 comments of “is this your change?”

Colin responds to them “No I’ll remove it.”

How has this happened? How can he mess it up so bad?

There was a project that I worked on where we delivered it in two stages. We merged our changes in, but there was one feature where we discovered a problem so we reverted one file.

Another team had merged from the master branch into their project branch to take our original changes. When they merged their project branch into master, they wrongly resolved the conflict and reintroduced the problematic change in that one file.

No idea what Colin did though, it’s almost like he had merged a different branch into his branch then had merged it to master. I’m out of theories. It took him 3 days and he had clearly messed it up.

Testing found 4 bugs with the project (which may be original bugs missed in the original testing before it got merged in). How many have they not found? That’s what worries me.

Who is a Software Developer?

The following blog Are You A Developer was recently shared amongst my colleagues.

The blog addresses Imposter Syndrome. It then reassures people they are a developer if they meet this definition:

A developer is a person who writes code.

David Walsh

I think it is a serious trivialisation of what a developer is. Several of my colleagues apparently agreed with this blog “100%”. I don’t understand how you can agree with it.

One of my colleagues not only agreed with this blog’s definition, but proceeded to say that developers and testers shouldn’t have different job titles, they should just be “Engineers”. Absolute nonsense. Not all Testers are interested in writing code. Some are interested in writing Automated Tests which requires programming knowledge, but other Testers just enjoy Manual testing which has no required programming knowledge.

So let’s address the quoted statement with some analogies.

If I cooked a meal, can I call myself a chef?

If I pull up a weed, am I a gardener?

If I paint a wall, am I a painter?

If I kick a football, am I a footballer?

It’s obvious you need a certain level of competency to be able to call yourself one of these things. If you play football in your free time, you can say you “play football”, but not many would say “I’m a footballer”, because it comes with the implication that they have an exceptional level of skill.

I was thinking you can’t simply state you can call yourself a Developer if you receive money for writing code. If it was a simple website you did for a friend, maybe you wouldn’t be skilled enough to be employed in a full time job.

Conversely maybe you make brilliant websites in your free time but you have other passions for your full-time job. Maybe you are good enough to declare yourself as a developer, but you just aren’t a “professional” developer.

What about developers that don’t receive money but only work in Open Source projects? At least the community would give them recognition, so at that point, I think they can call themselves a developer.

So it definitely seems money isn’t a factor.

So who determines whether someone is a developer? Do you self-assess? or is it when you get a certain level of kudos from your peers?

When you look at the people I often write about like Colin and Derek, are they developers? Well, they have had a job for years, and managed to get lucky to be promoted to Senior. On paper they are more successful than I, but I think you’d be crazy to imply they are at the level I am; and I’m not anywhere near the best in the company. Maybe we are all developers but there’s good ones and bad ones.

Ideally, Job Titles should reflect people’s skill but they aren’t a perfect system. But I think it is clear you have exceptional/great/ok/poor developers, and everyone else below this skill level, just isn’t a developer.

So if you have followed a tutorial, copied some code and ran it; are you a developer?

No. But keep working, and maybe you will be. Then work your way through the ranks.

Nerd Dad-Jokes

Javascript developer Wes Bos is maintaining a list of nerd Dad-jokes. They range in quality and many only make sense if you are familiar with programming languages.

https://github.com/wesbos/dad-jokes

Here is my favourite joke:

I went to a street where the houses were numbered 8k, 16k, 32k, 64k, 128k, 256k and 512k.

It was a trip down Memory Lane.

If that is too nerdy for you, have some pizza humour instead:

Why My Project Sucks

This is basically a follow up to the previous blog. So here is why my project sucks…

Firstly we are distributed across two offices with the justification of “the people in the other office need to feel involved”, or that is what one manager explained to me. They could have just assigned them their own important project rather than unnecessarily split the team.  Due to the office split, half the team were managed by the person actually assigned as the Team Manager, and the others were line managed by a manager in the other office who was primarily the Team Manager of a different team.

That manager was in charge of (what I liked to call) Team Duplicate who kept on duplicating our work. It’s approaching a year since our project started and we don’t really have much to show for it. However, what we did do; they wanted to directly duplicate (either directly using our code, or basically copy and paste) to have a slight spin on it.

Half the team aren’t interested in doing Code Reviews. This slows you down when you start coding a feature that relies on some other work, but yet it isn’t committed yet, because it hasn’t been reviewed. It then becomes a bit fiddly to manage code branches and merging code.

Unclear requirements. It seemed one person in the “Product” Team was making them up, rather than looking at contractual requirements or features that users actually desired.

The Product Owner didn’t take ownership of the requirements. This is linked to the above, but also he kept on saying “this is a technical project and I’m not a technical person.” No, Requirements are written as “User Stories” which are from a User’s point of view. It’s up to developers to discuss the technical implementation details. We didn’t have requirements from a user’s point of view, so it was difficult to understand what the end goal was. If the Product Owner actually wrote User Stories that were well-defined, it would highlight what UI designs we need from the UX Designers, and they can pass the work onto the UI Controls team. Additionally, with clearer requirements, it would probably highlight the distinction between my team and Team Duplicate.

The Team Manager added some ideas he wanted people to look at, but they weren’t backed up to a requirement. Again, they were a technical implementation detail, but what were we implementing? In the refinement sessions, we kept on pushing these “User Stories” down the backlog, but the Team Manager was reluctant to remove it outright, because “we may need it. It could come in handy one day.” If the Product Owner took ownership, he would have just binned these so-called requirements.

Due to slow progress due to many of the above reasons, we had a high turnover of staff. Most people that moved, simply switched projects, although I think one person did leave the business. We have a team of 9, and have had 5 replacements over 7 months. One person partially moved teams. He seemed to shift his focus to help another team, but seemed to dabble in both projects. It really felt like he didn’t care about the project anymore.

Conversation With My Line Manager – A Project Review

My manager asked me how the project is going. I was honest with him. I stated most of my concerns.

First of all, the teams aren’t well defined. We have some User Stories that seem like they would sit better with the team handling Authentication. We also have work that shouldn’t be much work on our side, as long as the UI Controls team have created the controls we need… but they haven’t – so that work has to be marked as “blocked”. Then you also have what I call “Team Duplicate” who are just duplicating our work.

I ask my manager what Team Duplicate is for, and why they just don’t merge with my team. He doesn’t give a straight answer, he just says:

“trust me, there is a difference”.

Line Manager

He is leading that team, and he can’t even explain their purpose.

I also said we don’t have many User Stories that are true User Stories. They have that name because they are from a User’s point of view. They should be defined like “As an admin user, I want to manage member’s privileges so they can access confidential records”. They shouldn’t be “As a menu, I want to provide options for the user to click”. Seriously, we do have some written like that.

My manager said my opinion was interesting, because someone else had said the same issues to him.

“Oh, so are you going to do something about it?”

Me

“No, it’s not my responsibility”

Line Manager

Brilliant. Multiple of his line reports are complaining about big problems but he won’t feed it back. Why can’t managers manage all of a sudden? They were fine last year. Now they have all given up and forgot their skills.

I could raise the issues myself I suppose, but it didn’t used to be this way. Also, part of my problem is the team he is managing, but he doesn’t agree there is a problem there.

Batch File Shenanigans

I was running a batch file (a script containing a series of command line commands) and it was randomly closing without displaying any errors. A developer, Lee had recently made changes to this script. I had posted a message to state the problems I was having, and he messages me. The exchange roughly went like this:

Lee: “I can help, share your screen”

Me: “You will just see it close though; there’s no errors”

Lee: “No, just share, we will make it work. I just need 5 minutes”

Me: “Oh, do you have an idea of why it isn’t working then?”

Lee: “No, I need to see what you are doing first”

Me: “I’m running the batch file, and it closes, that is all you will see”

Not sure why he claimed it would only take 5 minutes. How did he pluck that estimate out of the air? After he would see it close, he was only going to get me to try all different workarounds. That is going to take way more time than 5 minutes.

There was a simple workaround that would allow me to get on with my work: simply revert his changes and carry on.

I reverted his changes, and carried on with my assigned work. After I finished my work, I did go back and work out what was causing it. I shared my findings with Lee, who made some changes and asked me to try it out. It didn’t work.

 did have to try several different variations of the script to help him come up with the proper solution. This back-and-forth ended up taking around an hour or so. 

I definitely didn’t have time to do that when he contacted me and claimed he would just need 5 mins. I’m glad I used my intuition.