Mini Musing #5: It Doesn’t Compile

I was having a nosey at the latest Pull Requests and there was one from Colin. Usually, there’s a good few mistakes in his code. The Lead Developer comments:

“Does this even compile”

To which Colin responds:

“No, lol”

He never learns. How many times does he have to make these mistakes to realise that: if you make a change, then test your changes? When there are unit tests, it’s a simple as clicking a button, then waiting a few seconds.

The API 2

I wrote in a previous blog (https://strangercodingtings.home.blog/2019/12/30/the-api/) about an API that we wanted but didn’t meet our needs.

Another month went by, and we contacted the team to get estimates when they plan on changing the API to actually be usable.

The response we got was that their project was finished, and all the developers have been reassigned to different projects.

Hang on! How can they write an API and not work alongside any team!? The whole point of it is to provide data to other teams, so how can other team’s not be involved?

It’s not like they didn’t know we wanted it, I was requesting data from them in the prior 2 months.

I’m not sure when they plan on scheduling this work in, but it’s just stupid.

Joined up working

I think it’s best if you have teams that are in the same location since meetings are easier to arrange and have fluid communication.

If you are in the same office, you can have ad-hoc face-to-face communication. You can all go into a meeting room and don’t need any conference-call equipment which can have all kinds of problems; disconnecting, low audio quality. Same time-zones means there are more hour slots available to arrange meetings in.

I’ve heard people imply that teams end up being distributed just so that the other offices feel like they “feel part of it”/feel integrated into the company. Yet giving them a dedicated project they are responsible for would probably achieve that better; they will have more responsibility/autonomy. Adding members from the main development office makes it feel like they are been supervised.

Many times, you rely on a third party of some kind (by third party, this could be another team within the company or a different company). Maybe the third party collects the data and you just retrieve it via an API. You don’t really care about how the data got there, just that you can use it and it works accurately. Your team that wrote the user interface feel like they have achieved something. The team that collated the data and provided the API feel like they have achieved something. The teams may only need to communicate for a minor part of it. The teams need to know the overall aim, and what parameters they need for the API. My point here is that you can have two different teams with some minor collaboration, but both feel like they have contributed massively to the overall goal of the project.

I think adding a remote worker for the hell of it is just inefficient. Unless they are exceptional and can’t be replaced by the talent you have locally, then its just adding in unnecessary inefficiencies and causing unnecessary bottlenecks (have to delay meetings due to time-zones), have to wait until the next working day to get a response, different countries having different National Holidays.

Window-dressing The Codebase

We have a report analysing our code that does the usual static analysis checks like Code Coverage, “Code Smells” etc.

One team boasted how their report was 100% code coverage and 0 Code Smells; a perfect score.

I thought it was strange because over the previous 3 weeks, many people had pointed out the many bugs their project had. If they do have 100% code coverage, then they aren’t testing the right things. Zero code smells seems suspicious too.

I had a little peek at their repository to spot any suspicious activity. One of the recent bugs stated “we have run out of switch statements”. Obviously, to us software developers – that is a very funny statement to make. What he meant was, they have a huge switch with 30 conditions and the report flags up switch statements that exceed 30 conditions. This is a “Code Smell” because it implies its a bad design.

You could address this warning by:

  • rewrite a large part of it to implement a better design
  • do nothing. The warning still flags it in the report.
  • suppress the warning so the report doesn’t show it.

The developer decided to make a code change, but didn’t bother with a better design. His new switch had 30 statements, but the “default case” then called another method which had another several conditions in it. It gets rid of the warning, but it makes the code more harder to read; so he has made it worse. Suppressing the warning keeps the code readable, but you will still be perceived to be fiddling the report.

Looking at other recent check-ins, the team had “temporarily” suppressed warnings and then logged Bugs to address them later. This is definitely fiddling the report. It makes the report look good, but increased their backlog of work, and wasted time. They could have done meaningful work and let the report do its job with reporting accurate figures.

Then they are highlighting their teams “success” to the managers. The managers don’t look much further than a report, so they are happy.

Just follow the instructions

There’s a team who chose to set-up a generated report every time a code build was triggered. This report will show the usual static analysis checks like Code Coverage, “Code Smells”, bugs etc. It was encouraged that other teams should set this up too; so we were told to contact Rory who was leading this initiative.

I took responsibility for setting this up for my team, so I contacted Rory who sent me a link and said “just follow the instructions”.

I look at the instructions and they seemed to be for setting up a new instance of a Report server, rather than making your build process utilise the existing Report server. Common sense told me he had sent me the wrong link. I asked him again.

He reiterates: “It’s really easy, just follow the instructions”.

I felt Rory was messing me about, so I asked another colleague who was also setting it up for his team. He told me that with Rory’s link, there was only one link within that page which showed you some sample configuration. Every other step listed wasn’t relevant. Yup, Rory was messing me about.

Once set up, you then get a “permission denied” because Rory needs to give your team explicit permissions to contact the Report server. Of course, even though I told him I was setting it up at the start of the day, he hasn’t bothered adding me to the authorized users. Instead, he then wants me to send a request on his Slack channel before he will grant me access.

The thing is, several other teams also needed to set it up, and they went through a similar process of being messed about.

Why didn’t he write some custom instructions? Most of the configuration could just be copied from one team to another.

Also, he always waited until teams were stating they were getting the “permission denied” before granting them access. Why couldn’t he just add them when they initially requested the instructions?

Absolutely infuriating.

Different Git Server

After being on a new project for a few months, Beavis is told he has to fix a bug in the old system. Now, both codebases are stored using Git source control, but they are located on different servers. Other than the initial connection, accessing them is the same, so if you are using the command line, the commands are exactly the same.

Beavis, a Senior Developer states that he has the code checked out from months ago, but it will be now out of date, so he needs to get the latest changes. He then says “do I need to create a new branch to get the latest code? And if so, do I create it on the server and sync it down, or create it locally and sync up?”

Beavis, it’s the same process you have been doing for the last few months. Sync to get the latest changes, then create a new local branch for your bug fix to go in.

In the end, I think he asked another developer who doesn’t understand Git very well and Beavis ends up cloning another copy of the code.

Facepalm.

Fighting His Corner

A few months back, there was a decision between two technologies, lets say it was a debate about Docker and Kubernetes. It was decided to proceed with Docker.

A manager, John said that he has instructions “from above” that we must use Kubernetes. Another manager, Jane seemed to protest about it even though it wouldn’t be anything to do with her. I was confused by this. It seemed really out of character and she didn’t even know the reasons why Kubernetes was dismissed. So it’s not like she actually had an opinion on the matter.

Anyway, further debates were had between John and a Senior Developer, and then I heard the Developer say that “John must go talk to Roy” – who was the major influence on the decision against Kubernetes.

Aaaaaah! that explains it. Roy is Jane’s boyfriend and she was defending his decision. That’s why she seemed belligerent.

It seems to be becoming a bit of a trend that people are supporting their friend’s ideas, blindly supporting a technology just because it appears trendy, or using unsubstantiated claims to support an idea.

2020 Vision

Recently, we have had a few meetings where Senior Management have given updates of the plans for the year. I always come out of these meetings non-the-wiser since they just talk buzzwords and marketing jargon. To me, it just translates to “we are doing work to improve our products”, but yet they ramble on for 45-60 mins.

I wrote down some words and phrases from the meeting. So here are the plans/vision/roadmap for 2020:

  1. interoperability
  2. driving efficiencies
  3. minimise the pipeline
  4. bringing on-stream
  5. embedding the modules
  6. mobility strategy
  7. rolling enhancement program
  8. put us in a strong position as we go through 2020
  9. decoupling the need for multiple products
  10. gain focus
  11. add value and retain customer base
  12. technical debt being addressed
  13. a step forward in innovation
  14. marketplace acceleration
  15. improve discoverability
  16. improve sign-up flows
  17. laying the architecture down
  18. building into propositions
  19. specifically aligned with the digital proposition
  20. product portfolio
  21. leverage across different markets
  22. release the roadmaps imminently

Team Duplicate

Part of my team’s work is basically to create a framework where other apps can be plugged into. So this framework has a menu bar and is responsible for functionality that can be used independently of which app you are using. A good example of that would be Chat functionality.

So a part of this project is to create a “proof of concept” (POC); have the “shell” with some sample apps. When other teams make an app, then it can be tested within this POC.

Recently, another team has been putting together a POC which demonstrates how applications can be integrated into the shell. Have I just repeated what I wrote above? Oh, yeah. They are duplicating our work.

Who came up with this idea? Who planned this work? What is the point of it?

I asked one of the developers what the point of his work was, and he replied “you will have to ask the team leader”. I’m thinking “hang on, you agreed to work with them and you don’t even know what the point is?”

Our POC has our shell with a couple of other apps that other teams have produced. The duplicate POC has our shell with some apps that their team has cobbled together. I just don’t understand this at all, not only is it inferior because it’s not using other team’s work; a few developers have just wasted weeks writing apps that no one will ever use. It will just be discarded at some point. Or that’s what I initially thought, but I did hear the manager who is in charge of this say something like “this will be the POC that teams will refer to going forward”.

The other week, one of Team Duplicate’s members, Liam joined our stand up. When we mentioned some upcoming work, he volunteered to speak to another team we were waiting on, which seemed very generous of him.

A few days later, I went to pick up this work item from our Backlog. So I asked Liam if he had any information about it. He then gave me a weird reply along the lines of “I don’t think we need you unfortunately”. I was thinking “wtf, you are firing me with no authority!?”.

I then found out a member of his team was already working on it and he thought I was asking if I could assist with their work. I told him it is on our Backlog and he was telling me it was on his team’s Backlog too.

Obviously, we are duplicating work. This illustrates it. We need the functionality for our POC, they need it for their Duplicate POC.

In the end I picked up a different requirement. I mentioned this to a developer in Team Duplicate and he said “oh yeah, I need to implement that too”. I was like “you are joking, right?”. He says he wasn’t. So I said “I’ll race you then”.

I implemented it first.

Angry Complaints

On our stand-up call, we were joined by Lyndsay from the UI Controls Team. Vincent mentions that we will require some extra controls for the work he was doing and Lyndsay responded angrily “I just checked the Slack channel and no one has requested this, how do you expect them to do the work if you haven’t asked?”. Chill out, it has just come to our attention.

After the stand-up Vincent goes in the Slack channel and posts. A developer from the UI Controls Team responds negatively. He angrily stated that its not his team’s responsibility to do all the work, and maybe Vincent should do it. Lyndsay liked his response. It completely looked like Vincent had been set up.

A few days later, our Product Owner suggests we should work in a stricter Sprint approach, so we end the two week period with an end-of-sprint demo. At the end of the call, Lyndsay starts complaining that no one has done a demo or even announced one. She then says when the Development Manager comes back from holiday in a few days time, he won’t be happy.

I’m wondering how Lyndsay expects us to take her seriously when the Product Owner had only just announced the intention to create a demo, then she starts kicking off about the lack of demos.

I’m also wondering how things can be fine for months, then all of a sudden, Lyndsay made it feel like we are doing everything wrong. It’s like when we used to log a bug, and then a Test Manager would charge to your desk, demanding to triage it.