Tag: Software Development

Finishing the Apprentices work

In a previous blog, I was criticising some work done by an Apprentice: Apprentice Insanity

What actually happened with this is that it got deprioritised so was just shelved for a couple of months. Which is weird, because the original developer made out it was very urgent and wanted to check it in at the last minute.

When it was decided it was needed again, who got asked to finish it off? 

Yeah! me! What are the chances of that?

The Fix

The work was to show some messages to the user why a feature isn’t enabled for them. There can be several different reasons, but we never told the user why, until now.

So I load up our program with a valid user… I can’t use the feature anymore, and it tells me 5 reasons why I can’t use the feature. It’s completely broken then. A valid user should have allowed me to use the feature, and obviously show 0 reasons.

So I fixed a few bugs, and now I can use the feature, but there are still 3 reasons displayed. So it says I can’t use the feature; but I can, and I know I should be able to. 

I spent a lot of time looking through the code, and I saw that there is an existing file that did the validation, but the apprentice had created another file with some other validation rules in. If it is the same rules, then we are checking them twice? If they are different rules, then you end up in a situation like this; where I can use a feature, but the other file’s validation tells me I can’t.

So I end up deleting this extra file, and make the existing file be the code that returns the failed rules.

The new dialog he added looked nice enough, although the dialog was a bit small, and a few aspects of it wouldn’t actually meet our UX standards. When I looked at it, I saw that he had positioned all the controls by hand for a particular size, and so I had to do a lot of rework to get the controls to work on a larger dialog.

He also had code with complicated logic to adjust the size further. Complete hacky. So I got rid of all that too.

There was some other hacky code where he even had a comment along the lines of “for some reason the control can be duplicated, so if this happens, then we need to remove it”. After some experimentation and debugging, I eventually worked it out. What was happening was that the initialisation code was calling his new method twice. You would think that means the control was always added twice, but it wasn’t.

It turns out that there was some existing code that checked if a control was in position 1 in the grid, and if it was; it was then removed. Then there was some logic to re-add it based on a condition. So the control in position one is optional.

Position 1Control that sometimes gets displayed. Put new control here?
Position 2Control that is always displayed
Position 3Another Control that is always displayed
Illustrating the grid layout. There are 3 rows which can have controls in.

The Apprentice was adding his control to position 1 in the grid, but if the other control was there, then he added it to position 2 instead. So what was happening is – if he added his control to position 1, then the existing code then removed it, then when his logic is executed the second time, then it gets added to position 1 once more. So it displays correctly, but works “by coincidence”. 

If the existing control is added to position 1, his method then adds the new control to position 2, so when it executes the second time, it adds a duplicate to position 2. So then his hacky code kicks in and removes the duplicate. The simple solution; just create a new row in the grid for his new control. Delete the duplicate call. Delete the hack.

So it seems like he got into a mess by trying to cut corners, put in a hack when it didn’t work, but then it only worked intermittently and he didn’t understand why… so then put in some more hacks to cover it up. What you end up with is nonsense.

In the end, I had completely rewritten it, made the UI nicer, and got rid of all the bugs. Result.

The Demo

We had a demo arranged with someone who was basically representing a user. I was going to demo my code, but, an hour before the meeting, I got an important meeting invite. As a joke, I asked the Apprentice if he could cover me. He said he would be happy to do so. I told him I was joking, but if he really wanted to do it, then it would be appreciated. Like a nutcase, he agreed. With only about 45 minutes to prepare for the demo, I told him I had completely rewritten his code, so he may be a bit lost. 

He chose to demo from his existing, broken code.

My meeting turned out to be really short, so I joined the demo as the Apprentice was trying to explain a feature, after it crashed and somehow wiped the contents of an existing dialog, much to the confusion of the Representative.

I saved the day at that point and demoed the proper, working code.

Afterwards, one of my colleagues said to me 

“How the hell can you demo something THAT broken?”

concerned colleague

I said he is “a complete legend”.

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.