Tag: decisions

Self-inflicted problems

Instead of reinventing the wheel, Software Developers like reusing code. When using Javascript, a common place to use such code is NPM; Node Package Manager.

The recent NPM incident caused malware to be shared via many NPM packages. As far as I understood, I believe Github security tokens were stolen which allowed impersonation to check in malware and propagate to more packages.

As a precaution, we were told to cease development so you had hundreds of developers sitting idle.

We knew our teams didn’t use these packages directly but I suppose investigation was needed for transitive dependencies, and there was always the risk of packages we did use suddenly being infected, but we could just stop upgrading to new versions.

We thought it would only take a day or two, so I took the day off and would come back over the weekend to normality.

However more investigation was needed, then we had to switch over to a different internal NPM server with only approved packages being available.

I had no idea what the criteria is for approved packages. How do you know if something is secure other than the currently known, published security issues? Typically, bugs and fixes are added all the time. 

I think there was some kind lead time before new versions were accepted. I suppose it prevents this quick publication of malware if you just have a lead time of only taking packages more than a month old.

Since we had a new NPM server, we needed to publish packages to the new one, but we weren’t allowed to use the old ones. So new versions had to be published which then means you need to update all your software, and it’s a massive chain of dependencies involving all teams in the department.

I wasn’t personally involved but it sounded horrendous to coordinate and we were delayed by around 3.5 weeks.

We weren’t even affected by malware. We have loads of sub-companies in the overall group and no real incidents between them. Hundreds of developers were idle, and it was self-inflicted.

KM to miles

We had a form where the user can search for certain types of businesses in the area, and it displayed the distance from your location in miles.

One day, a user was posting all kinds of angry abuse because they said the distance was wildly inaccurate.

We were using a 3rd party API that was supposed to return the distances to the businesses in KM. It seemed that at some point, without us knowing, the API had changed to return the distance in miles, and our current code was expecting KM then we had code to convert it to miles. So now it was coming in as miles but we were manipulating the value to be wrong.

My reaction was that we should just inform the 3rd party to change it back. If their documentation says it is KM then they can’t change it without informing all the providers. If we changed our code, and the 3rd Party then reverted without informing us again, then the values would be wrong again.

A manager decided to go against my advice and told a team they needed to fix it. Soon, a Junior developer contacts me to say he is doing the fix and wants me to explain the situation and be available to review the code.

It’s a simple change, and he adds some unit tests. I pointed out a few more scenarios that he could add since our code was formatting to 2 decimal places. He could add tests for 3 or more decimal places in the data, and include larger values like >10 so you have 2 values before the decimal point.

So as far as I was concerned, if we HAVE TO make a change, then this is the simplest change and he has improved the codebase with the unit tests.

I approved the changes, and 2 other Senior Developers approved too.

When it was ready to go into the Main branch, another Senior flagged some duplicate code. He was correct, but it wasn’t a big deal because it’s one line of code. To “fix” it, you would need to create a new file for one method with one line of code which seemed overkill.

Then another Senior Developer questioned why one class called a method just to delegate to another method; when it could go direct. That scenario happens a lot, especially with design patterns where you want strict degrees of responsibility so the UI shouldn’t have logic. This was a very opinionated change, but since a Senior Developer had said it, then the Junior felt like they should do it.

So after the initial simple change, and 3 developers requesting some very simple changes, he was finally ready to commit the changes. Then a Principal Developer saw the change and said it was definitely the wrong thing to do since we need to get the 3rd party to revert their change. 

That was exactly what I said initially.

Annoyed at Autonomy

To illustrate how awkward it is these days to do something simple… we needed to disable a button, but it’s not clear to the user why the button is disabled. I quickly put a tooltip on the control.

I knew we needed approval from the UX team who are responsible for the “User Experience”, so I emailed them.

When our Product Owner was told, she was really annoyed and started moaning that I made a decision behind her back.

A decision hadn’t really been made, I was just exploring one simple option and trying to get things done. There was always the chance that UX wouldn’t agree with it, but it’s given them context and a possible solution.

The Product Owner didn’t like the tooltip at all. I did point out that other areas of the system do disable the button but don’t show a tooltip. So my button is an improvement that we show a tooltip – at least the users know why the button is disabled.

I suppose showing a tooltip for this disabled button is inconsistent UX, but that’s why I emailed the UX team. I know UX Team tend to hate “dynamic” UIs so don’t like things appearing/disappearing. This isn’t something we are removing, but just disabling/enabling.

After the Product Owner contacted UX, they wanted me to basically redo the dialog because other aspects don’t conform to their standards, but all that functionality has been around for years.

The bug/enhancement wasn’t actually reported by our users. It was just a Developer who decided it would be beneficial to change.

Conclusion

When there’s many people in charge of deciding what work needs to get done, and many people in charge of how things get implemented; making any change is a slow process and most things end up getting thrown on the backlog because the effort of implementing anything increases.

Remember when people used to know what they were doing?

Remember when people used to know what they were doing? those were the days.

“what concerns me the most is that there was a time where everything almost worked like clockwork and now it seems like more ruins every day”

Software Architect

“I am more surprised when something works”

Me

We used to be a company full of smart people, working effectively. Now we work slowly and people just cut corners and do incredibly dumb things. In more recent times, people now don’t think for themselves because they ask AI what code to write. Sometimes it’s absolute rubbish but they never reviewed it themselves; so it really is zero thought. You point it out to them that it’s not going to work, and they respond back with an overly polite message, clearly written by ChatGPT; which just adds insult to injury.

So it’s like developers don’t even develop because AI does it. Then they don’t do any dev-testing. Then the Testers don’t know what they are doing either.

Recently Testers have been installing our software on the application servers.

Even though one of the Lead Testers has been posting angry rants about it; it keeps on happening. The Lead Tester’s points were that it’s not representative of live, and how it takes up the RAM/processing time and lags out the app server for everyone else.

I don’t get why people got the idea to install the client on the app server, and remote on. You can’t think that is official. The servers were always configured to only allow 2 people on at once, so it’s not like the entire department can log on to test if it was the official process.

I just hate what this company has become. I feel like it’s just gonna keep getting worse with managers constantly encouraging people to use AI.

Unconscious Bias

There was a time where a group of people were hyping up “woke” topics, and the latest topic was “Unconscious bias” which is supposed to cause a certain degree of racism/sexism during the hiring or promotion process. Or maybe even leading to some microaggressions in meetings.

We were encouraged to watch a few courses on LinkedIn Learning, but it was not mandatory. Some of it was actually quite interesting.

There was one cringy moment where the presenter gave a trigger warning of sorts:

“if you feel an emotion, pause the video and deal with it. If you still feel the emotions, contact me and discuss it“

In my opinion, I think if you get overwhelmed with a simple LinkedIn Learning video, then you have bigger problems.

In my notes, I had written this claim but not sure what it means – because how do you even measure the bias:

“Research has shown that even a 1% bias in favor of promoting men changes the outcome.”

The following sounds like a decent philosophy though. If bias does exist then we do need to take it into account:

“By understanding that we’re all biased, we can make the decision to work together to be more conscious of our thoughts and actions when relating to others. Not only can we fix the current situation, we can then resolve not to do it again. Over time, it’s possible to learn to think and behave differently.”

She then makes the claim that even if you look at different aesthetics within a particular gender, you can notice trends which would suggest there is an unconscious bias at play:

“Blonde women earn 7% more than brunettes. Slim women make more money than obese.”

Some of the categories of bias are quite interesting. Halo bias probably does make a huge difference. You can say it’s like when you work with a Senior who you respect; whatever they claim in the next project you are tempted to back them and agree.

  • Halo bias – “admiring all of a person’s actions because of their praiseworthy actions in the past” 
  • Perception Bias – “the tendency to form stereotypes and assumptions about certain groups that makes it difficult to make an objective judgment about individual members of those groups.” 
  • Therefore it is difficult for women to be hired in gender perceived roles. E.g. software developer 
  • Confirmation bias –  “Seeking out evidence that confirms our initial perceptions, ignoring contrary information.” “We double-down and seek out information to justify our position.” 
  • GroupThink – When the desire for harmony or conformity in the group results in incorrect decision-making.
  • Performance Bias – Underestimate women’s performance but overestimate men’s. Men are often hired on future potential, women hired on past performance. 
  • Attribution bias – Less likely to credit women for success, but more blame for failure. Women’s contribution is less valuable. Women are more likely to be interrupted when speaking. 
  • Likability Bias – Expect men to be assertive so like them more when they are assertive, but have a negative response to women. Agreeable and nice is perceived as less competent so need to assert themselves to be effective, but then are less liked. 
  • Maternal bias – motherhood is perceived as less committed and less competent. Strongest kind of gender bias. Lower performance ratings, and lower pay in future. 
  • Affinity bias – gravitate to people like ourselves, dislike those that are different. More likely to give positive performance ratings to those that are similar. White men’s prominence means women and those of colour are negatively affected. 
  • Double discrimination (intersectionality): Women, and of colour is double discrimination. 3+ minority attributes make people feel like they don’t fit anywhere. 

“Woke” people seem to suggest that men are the problem when it comes to bias. However, I have seen claims that if you have an all-female panel they are often shown to be biassed towards hiring men. The claim was women don’t want to hire someone they perceive as a threat, or someone who is more attractive than them.

There was another LinkedIn course I watched that stressed the point that both genders show bias, sometimes in different ways.

There was a test where participants were shown pictures of men and women and they had to state (purely by stereotyping) if they associate them with “family” or “career”. Regardless of the participant’s gender, 76% of people associate women from the images with “family” rather than “career”.

There was also a claim which I would like to see what results back it up:

“Diverse teams tend to be more committed and work harder, and companies with more women in leadership tend to produce better business results.” 

During the hiring process, there is some scope to anonymise it somewhat to try and remove any bias against gender or race, in an attempt to judge purely on merit.

Innovation shambles

Recently, managers decided that every few months we should have an Innovation Week. The idea is that you can work on ideas that can improve our work processes or even add a new feature to our products. However, the time limit of one week is a bit limited to actually get something complete in my opinion.

To be efficient, we really need to come up with a great list of ideas before the innovation starts, otherwise it cuts into the week. Some people did submit ideas before, and others on the day.

The initial meeting quickly became a bit of a shambles. Paul had created a Miro board under a different account that the attendees didn’t have write permissions for. Even when we clicked the link to request access, and Paul claimed he approved it; it still didn’t work.

He then tried creating a different board, but that didn’t work. To not waste further time, we just posted ideas into the Microsoft Teams chat which then he transferred onto Miro.

Since the ideas were essentially just titles on the board, people were supposed to explain their ideas but I don’t think many explained too well. We probably needed some kind of formal process to:

  1. describe the problem, 
  2. ideas on how to solve,
  3. pros and cons, 
  4. any possible costs like software licences,
  5. prerequisites to be able to investigate or implement the idea.

Another thing was missed is that you have to have accounts to use many of the AI tools, and that was a focus of this month’s innovation. With a lot of software, it often needs a special licence for commercial use and we weren’t advised how to acquire licences. We had Github Copilot and Office Copilot but what about other AI tools?

One guy apologised for misunderstanding that the ideas should be process improvements and he had come up with an idea for our software that our users would use. Paul said he hadn’t misunderstood at all and we could suggest either process improvements or new features… but that’s not what the Miro board said. It was only for process improvements and so all but one idea was for process.

We needed to assign our names to them, so initially Paul tried to create a spreadsheet but couldn’t work out how to share it so we could all edit at the same time. He ended up pasting the ideas into a Microsoft Teams “Whiteboard” which I had never used before but it looked like the Miro boards.

There were loads of ideas, but many were of debatable value. However, like I stated, we never discussed them effectively. Without knowing the pros and cons or prioritised the business value; there were loads of ideas that definitely weren’t strong enough. So with a large list, it was hard to pick something to work on. Some of them would need more than one person, but what guarantee is there that the team will be full? Less likely when the list is so big.

So I asked the question if we should only put our name against 1 item, or vote for several so we can see which teams are full, then the full teams get approved. Paul said to only vote once otherwise it will look like teams are full, but you’d end up dropping out if another one of your votes were successful. I suppose that’s a good point, but only voting once will mean you could be the only person to vote on a team project, so would then have to choose something else anyway, or gamble and go by yourself.

With most people finally assigned (and many just disappearing, presumably to slack off), with many going solo, and some probably having more team members than required; we got told to communicate with our team members.

I was in a team of 3 but I thought the ideal team would just be a pair. I waited for 30 mins or so but the guy that came up with the idea hadn’t contacted me, and you would assume he would take the team leader position.

I then took initiative and added a group chat with my 2 team members, and after another 1.5 hours, I finally got a response from one person who asked how we should begin to plan. I responded with my notes I had created to set the scene. He suggested one extra point to my notes, then didn’t hear from him for the rest of the day. The other team member didn’t respond at all.

The next day, my manager contacted me and said I was assigned to help finish a project that was behind schedule so my “innovating” had come to an end.

Absolute shambles really.

The Chop

I was once contacted by my manager to review a particular code change, but with the instructions to actually select the Reject option if there was anything wrong with it.

Things seemed a little odd, so I was suspicious about the request. Usually you would only use the Reject option if it was completely the wrong approach, not just if one thing could be improved.

The change was an SQL data fix, but seemed for a bug that would rarely occur, so my instinct is that it should be run manually on the afflicted sites rather than sent out as part of the normal patching process. 

The normal process would mean the script would be run on all servers, and be subject to the usual slow “roll out” process; therefore delay its application to the affected site.

Looking at the comment from Support, it sounded like it was possibly just on one site.

There were 3 cases linked to it; 2 from the same site, 1 with a title of a completely different error number. Then the workaround is stated as “Re-add the Default Location to the Template” so they probably fixed it already. So maybe we didn’t even need to do anything.

Looking at the dates that it was logged, it seemed like it was classed as a minor bug so had a long time period to fix as per the Service Level agreement so I was sceptical it was still an issue after 2 years.

So my initial instinct says it should be applied as a manual patch, then reading the details from Support, it sounds like it was just on one site and they had already manually fixed it, presumably via the UI.

So I asked my manager if the site has been contacted to see if it is still a problem? Then we can just close it.

And that’s when my manager said

“His skills are currently being assessed so he’s been left to figure it out and told to ask for help if/when he needs it.”

Manager

So it seems like they have given him a bug to investigate then fix/close. Since he has struggled to resolve items before and been reluctant to ask for help, they have chosen this one to test if he is collaborating with the correct people. He didn’t, so they sacked him.

I haven’t encountered many sackings; everyone seems to imply it’s a lot of hassle, but certain managers are more willing to do it. Another approach is to declare that a “new opportunity” has come up and they will be placed in a new team to see if that causes an improvement.

Whether to log a new bug

Recently, we had the classic debate whether when discovering an (unrelated) problem, a bug fix:

  • should be rejected/marked as failed, 
  • or if you pass it, but log a new bug.

Sam said he had never logged a new bug if testing failed, even if this issue wasn’t called out in the bug report; in the description or recreation steps.

So to explain using this situation: I had fixed the Entity Framework code which saved a new row to the database table. The bug was for passing correct values into it, and my change was fine; the correct values were now saved in the appropriate columns in the new row. However, if you send multiple calls at once, Sam noticed it wasn’t incrementing the number by 2 as expected, only by 1 (the first call was then essentially being overwritten – a classic concurrency problem).

I think it’s reasonable to use the original Work Item (Bug Report) to flag any issues testers find, but once we confirm the new issue isn’t caused by my change it should go into its own Work Item. You might assess that the new bug could be fixed in a later release. It makes no sense to fail bug A because you found bug B. 

Sam is basically increasing scope, then moaning that we might fail the sprint, because we cannot complete the new item within the 2 week deadline.

Time management – A manager’s perspective

A manager recently posted the following. I think this sounds like good advice. Although I always think with us breaking work down into 2 week “sprints”, then the tasks just expand to fill the time allocated. So I think you need to process change or a collective mindset change across the team for this to actually work…

“Some thoughts on getting more for less…Individuals in all teams should analyse what they currently do in their role on a daily basis (i.e. where the time is spent). 

Then see what that could look like moving through transition (modernisation) and what next year could look like.

Right across the business, all individuals should take a moment to analyse where they spend their time each day (not high level timesheets, actual analysis). If we are ever going to get more productive output from already lean (stretched) teams then we need to work out where to optimise time and get the most quality output out of each day.

Examples of questions that individuals should ask themselves each day:
 
1. Am I managing my time properly? 10 minutes planning the start of your day can save hours. Write down what you would like to accomplish during the day. If you plan ahead and write it down, you can enjoy any breaks without thinking about work. Heads full of tasks that are not written down creates brain chaos meaning we break away from smart thinking.

2. Am I spending too much time playing around with ideas before I decide what to do? By the time I decide what to do there’s no time left. Stop procrastinating. Putting things off can affect your productivity.

3. Do I need to be in these long meetings? What am I contributing? What else could I be doing? Meetings are crazy expensive. I have been in meetings of 20 people where 3 people talk/contribute. Could I skip a meeting and watch the recording later?

4. Can this repetitive task I’m doing be automated? Should I be doing it or someone else more suited? Am I using technology to speed up my job? If I am a developer, do I spend too much time manual testing when it could be automated? Just because it’s always been done this way doesn’t mean it’s the right way.

5. Am I working in ‘smart mode’? Is there an easier way to accomplish what I’m doing? Am I over-elaborating? Finish unimportant tasks within 10 minutes.

6. If I have 5 things to complete concurrently, try allocating time to each task and set a timer. This speeds up work. Divide your day into time increments. Then, assign specific tasks during each portion of your day.

7. If you need to concentrate hard on certain tasks, then minimise distractions. Block time away from people.

8. Prioritise your tasks. Starting off with your most difficult or important tasks first can help you feel more accomplished.

9. Group similar tasks. When you focus on related assignments, you spend less mental energy context-switching between different tasks.

10. Finally, set aside personal time to disconnect from work. This can increase your productivity. A stressed and tired brain cannot work efficiently.”

Debate about ChecksumGenerator

I was working on recreating functionality in our new API. It was basically a copy-and-paste job from our current product.

I had another debate with the Team Lead who said I shouldn’t have copied the ChecksumGenerator, and wanted me to replace it with a Nuget package.

The idea of using existing packages is from the generic advice of “don’t reinvent the wheel“. If the code already exists and has been thoroughly tested by loads of people, then it’s best to use that. In terms of future fixes and enhancements, if it is a popular open-source package, then other developers will update it. If you rewrite the code for your own company’s use, you are stuck maintaining it.

However, in our case, we already have some code, we know it works since I took it from our other product and it’s been used for several years. It’s only 58 lines long and has no need to change.

The package he wanted me to reuse wasn’t actually that popular so it adds some risk using it. I had just finished my code changes and already ran all the tests, so any changes would need to be retested.

Isn’t using loads of packages just adding bloat? That is such a webapp thing to do. My brief experience of developing a React Application, has shown me that it uses a crazy amount of packages with a basic boilerplate application like create-react-app. Then anything you install has loads of other dependencies, and you end up having bloated install size and loads of potential security risks.

The Team Lead’s justification is that a ChecksumGenerator isn’t directly related to our API so shouldn’t be in our repo, and wants to “do things properly“. I think if you go that extreme then the software ends up in development hell. Which is exactly what has happened here because this API is part of a larger project that has been in development for about 7 years now.

It’s quite hard to win an argument against a Team Lead because unless the majority say that he is wrong, then what he says goes. We have a Junior in our team, then the other developer is the Team Lead’s best friend. Then the other two are Testers that don’t have much interest in a coding discussion like that. So it’s gonna be rare for someone to speak up and cast a winning vote there.

I asked my Software Architect friend what he thought:

“That’s completely senseless. Pretty much always use code that works, as long as it performs well as part of it ‘working’.
Does the new package have an allowable licence? 

You should ideally try to avoid dependencies”

Software Architect

I had a discussion with another colleague in another team. He mentioned that infamous time someone got angry and withdrew a package which took down a large part of the internet. I think we have mitigation for that scenario though.

Robert:

What if the package gets pulled?

Me:

I was about that yesterday. I think we mitigate it by having our own nuget store. So I think the package goes from the main nuget source, down to our local nuget store, then into our builds
might have made it up, but that's how I picture it
so unless you attempt to update the version, you always have a copy of the one you currently reference because it is cached on your server