Buzzwords

There’s a manager that constantly reels off jargon and buzzwords, then at the end of his speech, I always think “what the hell is going on?”.

I was watching a few of his video updates and wrote down a few phrases that took my interest. The first video was about “latest developments” and how these changes are going to “accelerate development” as we “integrate with teams“.

The next video asked “how do we get the backlog to illustrate we are moving in the right direction?” with a respect to “data-driven timelines”. There’s gonna be a “high level plan” which will allow us to “commence application development come Q2”. We can “tally up with the timeline” and when we “consider ourselves integration ready”, we then “help teams work with integration-ready architecture”. Finally, when we get “all bases covered”, “collectively we have a whole backlog and roadmap of work”.

Can we achieve this? Let’s hope it is clearer come Quarter Two.

The API

In our current project we need some user data to populate a screen with the user’s settings. I ask the team responsible for this data if they have an API we can call. It shouldn’t have been a surprise to them because we are replacing existing software and the requirements are the same – we just need to implement it using different technologies.

So I email them with the requirements. I want to pass them a UserId, and I want them to send me back the User’s Configuration in return. Easy.

A few days later they send me a meeting invite.

On the meeting they said they didn’t understand the requirement. I then show them the UI designs, and tell them that I need the data in order to populate a form for a particular user.

Two weeks later I get another invite. They still don’t understand what we want. So another team member explains to them.

The next day I get an email with their new design. I can call their API with an ID related to my application, then I have to do a separate API call but I can’t specify a user. The format it comes back in is JSON, but it’s not really conforming to the standard.

So you may expect some JSON about a film to look like this:

    {
        "title": "Gravity",
        "info": {
            "directors": ["Alfonso Cuaron"],
            "actors": [
                "Sandra Bullock",
                "George Clooney",
                "Ed Harris"
            ]
        }
    },

but instead they said they want to send this:

    {
        "title": "Gravity",
        "info": "{directors: [Alfonso Cuaron], actors:[Sandra Bullock, George Clooney, Ed Harris]}"
    },

So you can’t have nested objects which JSON is designed for. Instead, you just have 2 fields with everything smashed into one text string. Why?

Ignoring that though, after 3 months, they finally email to say it is ready. So I look at their Swagger documentation which shows all the API calls in a website, and even has a button that can trigger an API call so you can see an example response. “Brilliant” I thought, I can understand what they have done without writing any code or using a tool like Postman to send calls. It is simple as clicking a button. I click the button…but the message fails to send.

I then send an email, informing them that this doesn’t work. The developer says something along the lines of “we are in the process of changing the API”. What do you mean? I waited 3 months and you are saying it’s not ready – an hour after telling me it was ready!? He did get the Swagger documentation updated before the day was over, but I just don’t understand how it wasn’t updated as they were actually making the changes.

So after 3 months, we get an API that isn’t even suited to our needs. This is just madness because we will be the only consumer of at least one of the calls they implemented. Therefore, the API should be driven by our requirements. We shouldn’t be making two different calls, then doing some jiggery-pokery with the data, when it is easy for them just to send it back in the format we want.

Duplicate Builds

Recently, there’s been quite a few odd things our team has done and I haven’t put that much thought into them. So I have either:

  1. approved their Pull Request, putting my trust in the developer that it was the correct thing to do
  2. casually skimmed over something someone else has approved.

Then, when I spend more time in that area, I then think; “what the hell are we doing?”

I was making some tweaks to our build process and then thought “why do we have two builds for every check-in we do?”

So I look at the definitions and it’s basically this:

Build 1Build 2
Download and installDownload and install
Run linterRun linter
Run testsRun tests

Produce report
build steps

So the second build is just to produce a report, which it needs a valid build to produce. But it could just use Build 1. The sensible thing to do is just to delete Build 1, since Build 2 has the full steps we actually want.

So I ask the developer that set-up these builds and he said “it is quicker”.

So I’m like “what!? how?”

“it runs in parallel”

So? Both builds initially do the same thing, but one has an extra step so Build 2 takes longer. We have to wait until both builds complete before the code can be checked in. If Build 1 fails for some reason (e.g. Unit Test failure), then you are 99% guaranteed that Build 2 is gonna fail, therefore is a waste of time and money. The report can’t generate unless there’s a valid build, so the report may as well just use the existing build. Since they run in parallel, the total time is just the time of the longest running build e.g. Build 2.

He didn’t even seem convinced.

GitHub Actions

Probably a common thing I’ll discuss on this blog is people using technology just because it’s apparently cool. In a way, it is similar to when people write programs using languages they know, rather than using an appropriate language for the task. It’s like the mentality is “I’ve learned this thing, so I’m gonna use it!”

Teams have been using AWS Code Build to build their applications. Then one team decides to be different and try some new technology; GitHub actions https://github.com/features/actions. When their source code is on GitHub, it does make sense to use Build tools there, but at the same time, every other team is using AWS, so why not be consistent? To be fair, I guess a good reason to use it is that you get 2,000 free minutes a month, so I guess it is cheaper for one team to use it.

Now, there’s a couple of things I want to mention here.

A) This team that uses GitHub Actions has many people that I mentioned in the Anti-Microsoft blog (https://strangercodingtings.home.blog/2019/10/29/nerd-elitists-1-anti-microsoft/). Now, the funny thing is that Microsoft acquired GitHub back in June 2018 (https://techcrunch.com/2018/06/04/microsoft-has-acquired-github-for-7-5b-in-microsoft-stock/), and therefore, their servers are running on Microsoft’s Azure platform. I do wonder if those guys are aware of this.

“GitHub hosts Linux and Windows runners on Standard_DS2_v2 virtual machines in Microsoft Azure with the GitHub Actions runner application installed.”

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners#about-github-hosted-runners

B) In my team, we have 4 repositories, and 3 were set up to use AWS Code Build. I submitted a Pull Request to configure the fourth. I get a comment on my Pull Request saying “changes are OK, but I recommend using GitHub Actions instead”. No justification for it, he just thinks it’s cool, so wants me to undo the few hours work. I can understand if there was a strong advantage for using GitHub Actions over Code Build, and if there is, I would want all 4 repositories converting, not just 1. It just adds to the confusion, and adds to the things you need to learn and maintain.

William

I’m gonna create a new character called William because I have a good feeling he will be a good source of stories, so don’t want to group his stories with Colin.

There was a time I was looking through the recent changes to our software and I saw someone had added some additional error logging. When people have done this in the past, its because there is a bug they cannot recreate, so they need to add additional logging code to gather extra information in order to diagnose the issue.

Anyway, I look at the code and realise that what they were logging wouldn’t be helpful at all. I asked the developer what he hoped to achieve and he said “William told me to do it.” So I was like “If William asked you to jump off a cliff would you do it?“. He replied “But William is a Senior“. I was like “so what? you need to consider things for yourself“.

Recently, William has got involved in our project and has been trying to help decide how to approach our architecture.

We were discussing how users could be updated with real-time changes to data. William stated we couldn’t use SignalR. I asked why and he gave me a shocked look as if it was obvious. “It doesn’t work with web browsers” he said. Weird, I thought, because a partner product uses SignalR for their website.

SignalR supports “server push” functionality, in which server code can call out to client code in the browser using Remote Procedure Calls (RPC), rather than the request-response model common on the web today.

https://docs.microsoft.com/en-us/aspnet/signalr/overview/getting-started/introduction-to-signalr

I was looking into a solution involving Web Sockets and he came over and told me it has been ruled out because it is limited to 1 million connections. I was like “1 million connections? How many do we need?“. He was like “we need to think bigger than that, Websockets isn’t scalable“.

I asked around to get an idea of our current userbase. Turns out we have ~180,000 users, but around half will be active at any one time. So even if we did scale it up, 1 million is more than enough. I was speaking to one of the Architects and he reckoned that the 1 milllion limit can be surpassed with certain implementations.

Anyway, it got me thinking that maybe you shouldn’t always assume people know what they are talking about. William states things with such confidence that it sounds like he knows what he is doing, but really; it’s just the first idea that popped into his head.

“As a junior developer, hearing others say “I don’t know” is extremely reassuring and erases the common misconception that experienced developers know the answer to every question, and have a solution in the back of their mind for every type of problem. Admitting you don’t know something is nothing to be embarrassed of — instead, it’s a new learning opportunity for everyone involved! It may even lead to another occasion to pair programming or debug a problem together”

https://dev.to/httpspauline/5-ways-to-create-a-junior-developer-friendly-culture-3n4

So if William admitted that he needed to do some research, we could have investigated various messaging technologies.

Without me questioning his statements, we could have rejected two perfectly viable options.

Website Bundle Size

I was looking through our application and removing redundant code. I was checking the size of our application and wondered if I could reduce the size. A smaller download size will give the user a better user experience.

How long will you wait for a website to load before you give up and go somewhere else? Ten seconds? Twenty seconds? Apparently, nearly half of us won’t wait even three seconds.

https://www.bbc.co.uk/news/business-37100091

In my research, I found this blog https://www.freecodecamp.org/news/3-easy-ways-to-boost-your-web-application-performance/ which mentions a few areas to look at; reducing image sizes, code-splitting/lazy loading, and reducing the bundle size.

For the third point, it gives an example of a Javascript date library called “moment” which is something my team was using. When I looked at our bundle stats, Moment was contributing to 30% of the size of our app! We only used it as part of a Date picker control which we use once. The blog recommended a website called Bundlephobia e.g. https://bundlephobia.com/result?p=moment@2.24.0 which shows you the size, and recommends some alternative libraries. Moment is 231.7kB and 65.9kb (compressed) whereas “daysjs” is only 6.5kB and 2.76 compressed. If you look at their time stats, the site reckons it will take around 1 second longer to use Moment rather than DayJS.

According to research from digital performance measurement firm Dynatrace, just a half second difference in page load times can make a 10% difference in sales for an online retailer.

https://www.bbc.co.uk/news/business-37100091

Git Hub user martinheidegger logged this very issue back in Aug 2016 https://github.com/moment/moment/issues/3376

It looks like development/maintenance has slowed down this year, but I’m surprised that the Moment library hasn’t been abandoned completely. Loads of people have highlighted the size is a problem, yet no one has actually sorted the issue out after all these years.

When the research highlights how important fast speeds are to users, then you would think developers would put more important on performance.

Untested illogical code

A Junior Developer sent a Code Review for some C# code. There was a bug that if a user didn’t have permission for a particular record, the code would try and look for the record and couldn’t find it, then it would then crash.

Not only was the “fix” a classic case of merely hiding the bug, rather than addressing the fact of why the code was trying to find the record in the first place – but the fix produced couldn’t possibly work. The Junior Developer had written some code like this:

public boolean HasPermissionToAccess(int recordId)
{
 try
 {
    records.singleOrDefault(record => record.id == recordId);
    return true;
 }
 catch(InvalidOperationException)
 {
    return false;
 }
}

Another developer had beat me to the review, but he nicely asked questions to hint that this can’t possibly do anything beneficial; along the lines of “can you tell me where the exception is thrown?” and “can you tell explain why these return values work?”. I would have just said “you cannot possibly have tested this”.

The thing is, the Junior then gave an answer like “the singleOrDefault line will return null if the user doesn’t have permission”.

Yes that is correct Junior, but you ain’t doing anything with the return value. You are returning “true” regardless of what happens. i.e the user “HasPermissionToAccess”. Surely it should return “false”? Also how can the catch block ever execute? singleOrDefault will never throw that exception. Since his new method always returns true, then the calling code will still crash in the exact same place it did before.

I don’t understand how you can write code with the aim of fixing a crash, but it doesn’t even fix the crash. On a positive note, I guess it didn’t introduce any other issue, other than being completely redundant.

Ignoring Instructions

I was about to leave work when Colin asked me if I knew how to set up a messaging system. I said I couldn’t remember the exact details but I’ll have a quick check because I was sure I had written a guide on how to do it.

Anyway, I emailed him some details. I attached a security certificate to the email but explained it was probably expired, but he could grab a current one from the test servers. I also added a SQL script to modify his database settings to match the certificate.

The next day he never told me he had problems, but I heard him talking to the Lead Developer about his issues around 11:30. The Lead Developer told him that he hadn’t updated his settings. When Colin showed him what he had changed on his database, the Lead Developer told him he had updated the wrong table.

How could he have updated the wrong table? I had sent him the script.

Anyway, 10 minutes later he got it working with the Lead Developer’s help. Another developer comes over and asks Colin what he did to fix it. Colin says “my certificate had expired, and I had updated the wrong table”.

So the two things I told Colin to do, he didn’t bother doing. If he had followed my instructions he could have saved around 2.5 hours.

Code Amnesia

On Monday, Colin was struggling to recreate a bug even though he had recreated it on Friday. I knew he had been struggling for a few hours, so I decided to go over and talk to him. I always love a challenge of recreating obscure bugs.

He gave me a quick demo of what he was doing, and gave me a quick glimpse of the code.

I went back to my desk, and within minutes, I had successfully recreated it. Then I asked him what the difference was between my version, the version he recreated on, and the version he was struggling to recreate on. I knew my version was a version or so behind. The test environment he had previously recreated it on could have been updated Monday morning. So it seemed the simplest explanation is that someone had already checked in a fix sometime on Friday.

Then I remembered part of the code he had showed me, and thought that one of the methods sounds like it takes this scenario into account. So I ask Colin to show me the code again. I read the code.

Timeinints: “That code should stop this issue from happening. “Who wrote it?”.

So Colin annotates it. The annotation states “Local”

Timeinints: “Colin, you wrote that code”

Colin: “Did I? I don’t remember.” He stares at it for a few seconds. “Oh actually, I did write that as a speculative fix, but then I couldn’t test it out at the time”.

So he had spent most of Monday trying to recreate an issue he had already fixed on the Friday. He just didn’t remember fixing it.

Innovation Day

Every so often, people raise the idea of tech companies having an Innovation Day. So maybe every Friday, people can put down their usual work, and do a personal project instead; maybe using a language they aren’t familiar with. Sometimes we have explored this idea, but usually just for one or two days.

I’m always skeptical, because I often find fixing a bug, or making a simple feature will take a day or two, often even longer. To expect some kind of prototype in such a limited time always seems an impossible ask to me.

Recently, a group of people have been allowed to have a full Innovation Day each week. I was speaking to one of the guys and he was saying that they plan to stop it since one day a week isn’t enough time. A month quickly goes by and that’s only 4 days work.

When the innovation is supposed to be meaningful and integrated into new projects, these new projects will have come a long way and then it’s awkward to utilise it. Recently there have been projects that have been scrapped or required a major overhaul because of ideas that have either come out of the Innovation Day, or by some idea someone suddenly had. The earlier people know about requirements, the easier it is to integrate into the project. Trying to implement it later is hard, or even impossible; so the project gets scrapped and they all start again.

Another problem with just having a single day is that you could book that day off as annual leave, or maybe you are ill. If it is a team thing, what happens if someone has the day off and you end up being on your own?

Anyway, I was low on work, so thought I’d pay a visit to a particular pair of developers that were working on a feature relevant to my project. Turns out one of them was ill, and one of them had some important meetings in the morning so would be a few hours late.

Anyway, I end up meeting him and we had problems getting the previous week’s changes to build. There were quite a few people missing from the overall group too, and some developers seemed to take an overly long lunch break – like 1.5 hours. Then when they did return, they ended up switching conversation between work and banter, so much so; that I reckon they only were productive half the afternoon.

So how much benefit can a day a week really be? It’s seems unreasonable to expect zero complications and 100% efficiency, so it seems a waste of time.

I was speaking to another colleague about the Innovation Day and he was surprised that it was limited to a select group of people. He said entire teams should be innovating so they buy in to the ideas, rather than someone else saying “I did this in the Innovation Day, so your team should do it too”. It also links back to the comments on time; that you don’t want a team to have got so far into the project, then be told to rewrite it with a different style architecture.