Discovering the Programming Process

An automated tester posts a blog which got loads of “likes” and comments from Managers. One example comment was “what a well-written and informative blog”.

I read it, then read it again, then read it again. I’m so confused.

He begins by explaining how they are testing an API using Postman and have a collection of tests that they need to check-in to source control. Fair enough.

Then they say how it’s a tedious process where each team member needs to download the files, try them out, then mail the developer/tester who wrote the tests with their comments, then the process repeats.

I’m thinking “what sort of crazy process is this? This is what Source Control and the Code Review process were invented for”. You have side-by-side comparisons (“current file” to “changed file”) so you can see what they have changed. You can write comments directly alongside the code for them to read and make changes.

I must be missing something.

Then he explains that they needed to decide where to save their files. The Postman software encouraged them to store the files in Postman’s cloud service. “No, we aren’t gonna do that!” he writes as if it is some kind of security risk to save your files online. Instead, he is gonna save them online in GitHub. I send him a message about it, and he admits that I’m right, it’s just that he felt Github was more secure.

My loyal readers will be thinking “Hang on, haven’t you come across this scenario before?”. Oh yeah, here it is: GitHub Actions Are Secure. Yet another staff member chatting nonsense to sound good to the Managers and hype up GitHub. “We are taking security seriously with our decisions! This software is more secure because I said it is”. Has GitHub hypnotised everyone or something? They must have some propaganda machine. I’m not saying it isn’t secure, but claiming everything else isn’t as secure without evidence is just weird.

He then says how they wrote their own test library in Javascript which slowed them down because you don’t get great autocomplete support in the IDE. I’m thinking “maybe use Typescript”. He then explains that after writing their own library, they discover Jest; the most popular Javascript testing library. Hang on, how did you overlook the most popular testing library?

He then concludes that it is best to:

Use GitHub for source control
Take advantage of side-by-side diffs, and publish feedback in this code review process
Use Jest for Javascript Testing
Use Typescript to give type-safety and autocomplete support in the IDE

Tell me something I don’t know.

Then managers are drooling over these revelations, even though this is common practice to Javascript developers and probably has been for several years.

I want to know how much time his team has wasted messing about. Surely they didn’t start the project pretending software development had just been invented?

Using the Build Server to test your code

I was having a nosey at Pull Requests, and I saw one that was titled “Code to get the rest of the team up and running”.

I have a look, and after he sent the initial request, there were 2 other additional fixes along the lines of “fix broken build”. The next day, I checked back and there were 7 other additional fixes, again along the lines of “fix broken build”.

9 attempts.

Clearly, he wrote the code, and didn’t test it at all. Didn’t even build it. He just submitted the code, and let the Continuous Integration build run, and fail. Then run and fail, then run and fail… repeat until we all go insane.

They do say the definition of insanity is to do the same action multiple times and expect a different result.

9 attempts.

Still can’t get over it. At what point do you realise it’s best to actually test your changes?

I guess in his mind, he wanted to check in the code as quickly as possible so he can “get the rest of the team up and running”, but surely you have got to realise your approach isn’t working. When your “quick change” has been spread over 2 days; it is no longer quick.

I love it when people cut corners to save time…but in the end it takes 5 times as long as it would have done if they had done it properly.

9 attempts.

But wait, there’s more. Well, there will always be more because he doesn’t learn from his mistakes.

His next set of changes was to add support to handle a new message. His colleague reviewed his code and left a comment like “this line of code will prevent the message from being sent”. Yes that is right, he is adding a new message, and the message won’t even send. Yet he is sending it for review. Obviously didn’t test it; just coded it blind like before.

So he makes the change, makes some other smaller suggested tweaks. The build fails with Code Analysis errors which he would have found if he had actually built his changes locally. You know, step 1 when you begin to test your changes, and precisely the problem he encountered the week prior with his previous change.

The reviewer makes another comment, doubting some other part of his code would work. He replies:

“I think I will have to abandon this review and get this tested.”
Insane Developer

You know what makes this worse? He used to be employed as a software tester.

Apprentice Insanity

An apprentice sends a code review with the following code comment in it:

“Need to check this logic…but right now; I may be going insane. Wait, WTF is this?”

Instantly, I doubt how good the rest of the code is. I wasn’t assigned to officially review it, but I knew the Lead Developer would tear it apart. Not just for that comment, but the Apprentice had written this as a disclaimer:

“There are no new unit tests because this will be submitted later. This work needs to be quickly checked in and tested.”

Even though he had already technically missed the deadline. Maybe he got special permission from the Product managers, but if not, he had at least 2 weeks to work on it for the next release.

Cutting unit tests probably cost him time in the long run. I wouldn’t imagine he wrote all the code and just tested it once. It would be a case of implementing the solution in stages, making tweaks and repeating the same manual tests with each change. If he had written the Unit Tests early, he could have run the tests as he is refactoring and adding features. Then in the end he would have fully tested code which works. Instead, he has untested code which we aren’t confident if it works properly, and wants to check it at the last minute with less time for the Testers to run manual tests against it.

3 weeks later, he still hadn’t checked it in. Probably a good job this change got rejected by a Lead Developer for not having Unit Tests.

I’ve seen this kind of scenario before where people cut tests or a feature that was “nice to have” in order to meet a deadline. They say they will finish it after it is checked in, but usually something with higher priority comes along and they do that instead. If it wasn’t important enough for the original deadline, then I guess it is deemed as extremely low priority by any manager. Then it never gets done.

It’s funny how many code comments you see along the lines of “//Check what this does”, “//Finish this”, “//check the performance”, and then you wonder:

How did this get checked in? (well, probably fast-approaching deadlines like I’ve explained)
What feature is missing? Is there a bug with this code?

If you write unit tests early, then you achieve a higher quality solution earlier on, and you gain confidence in the code.

The worst scenario is: complicated code with no tests, written by an apprentice, who makes a statement which expresses his uncertainty if the code actually works.

Open Source Culture

Last year, a developer suggested we get involved in contributing to open source. It’s a good way of getting our company name out there and also it gives back to the community – given that we are using many open source libraries ourselves.

Recently, a developer had used an open source library, but needed to make a small change to it. He had created a “fork” which meant he had the code showing up in his GitHub profile. An audit report runs on our profiles and it was flagged up for investigation because the repository had “public” visibility. The intent of the report is just for someone to check we don’t have our proprietary code exposed publicly.

There was some discussion, with the end result being the developer was made to remove the code. He cited “they didn’t want my name being traced back to the business”.

I wish we would just commit to ideas. Are we Open Source-friendly, or not?

This Linux Problem Is Following Me Around

I had a nosey at another team’s Slack channel. There were a few team members complaining that things didn’t work on their machine because the commands were written for Linux and they had Windows.

Why was this a problem now? Their team had been together for a year. Well, a new team member had joined and he had used his “seniority” to introduce some new tech, written it with his Linux laptop and screwed his team over.

Then he replies something along the lines of “I don’t know Windows so I can’t help, but this is frustrating, so someone needs to do something about it because this problem is following me around“.

Well, dude, the problem is you. Stop setting up processes that aren’t compatible with your team members.

What I found interesting was that the complaints weren’t aimed at him. It was like they were following the “don’t hate the player, hate the game” kind of mentality… which I think was just because the developer has a fancy rank and they didn’t want to disrespect him.

It’s definitely his fault, and he should take responsibility to fix it. Maybe use a Windows computer; that is one solution.

Exposing a Secret Team

There’s been quite a few times where projects have been scrapped, or switched to a completely different team.

A project which is making a library (that I reckon will be used by every team) quietly got abandoned, then reassigned to a different team. The reassignment wasn’t communicated either. I found out just by browsing the repositories, and saw one with similar functionality.

My team felt the need to use such a feature and so we posted in Slack asking if anyone had plans/advice. Later that day, a big announcement was sent out, stating that people will need this, and teams should contact them for further info.

We contacted them for further info, then they said they don’t have an API because they didn’t consider people would want to use it just yet.

Are they having a laugh?

Why does it take people to ask about a project to then publicise the existence of it. Then it turns out it wasn’t even ready for other teams to even consider using.

The general advice to teams was to proceed “API first”, so that way dependent teams aren’t blocked. Then this team, whose entire existence is to work with pretty much every team – comes out with “we didn’t consider people would want to use it just yet”. Why were they working in secret?

Anyway, that’s even more work to block on our backlog then.

Derek: 0 Points

I made this blog primarily to talk about Derek and I seem to have convinced myself I had already written this story, but it seems I haven’t.

I have often thought about how to measure a developer’s performance and it seems an impossible task. The best idea I had was to somehow assign the same work to 2 different developers and see who writes it faster, who writes the cleanest solution, and if there are any bugs in the produced code.

There was some work where Derek had to add a new user control in a certain condition. He had spent over a week on it, then kept on ranting about it in the stand-up meetings. He kept on saying how it was too big for one piece of work and we should have refined it more. I told him he could have split up the work into small Tasks and completed them separately. There was nothing stopping him doing so, but he kept on using it as an excuse. “It’s too big, my focus keeps jumping between many files as I add code here and there”.

It got to the 11^th work day, and he said he was on annual leave in the afternoon, and he was trying to solve an error but he didn’t expect to get to the bottom of it. I told him to write down his findings, and shelve his code. I would take a look at it in the afternoon when I was free.

He doesn’t bother sending me any explanation of the problem, but it’s not a big deal; I’ll grab his code and test it out.

I take his code and look through his changes. He has changed way more files that I anticipated. He has put the main part of the code in a file I didn’t expect. The code that looked reasonable still needed to be tidied up.

I reverted his changes from several files, moved his main code to a different location, refactored the code so it was clearer, added the rest of the features that were mentioned in the user story. The next morning, I did a bit more refactoring, added a few unit tests. Job done. 1.5 days compared to Derek’s 10.5.

You may tell me that he gave me a head-start. I would argue that I wasted time trying to understand his code and I ended up deleting the majority of it, and the bits that I kept – I could have written within minutes anyway. It would have probably been quicker if I had started from scratch.

When we actually planned that piece of work, I expected it to take 5 days. In hindsight I was wrong; it was only 1.5, but Derek took 10.5 and moaned it was too big. 10 working days is a full 2 week “sprint”, and he failed to deliver any work during that time.

If you wonder how much better I am than Derek and wanted some kind of measurement, I reckon I am 9 days better. My solution met the requirements and there were 0 bugs.

Describing a Bug That We Are Already Fixing

William comes over and tells us of a problem he was looking at, but reckons it belongs to our team. Paul tells him that I am looking at it and have a potential fix. Paul explains how the fix works.

William then explains what the problem is. Paul tells him he knows what the problem is; we have a fix. William argues that it won’t work. I tell him I have a potential fix. William says it won’t work; he has witnessed the problem. I tell him I have a fix.

He still isn’t happy, he tells his colleague to demo it. He opens the menu, and is about to switch to the problematic application; but nothing shows in the menu.

William explains “Yeah, I broke it last night. Well, you can enter the URL, that will work”. His colleague corrects him and tells him that if the menu is broke, then the URL won’t work either.

William goes back to his PC, fixes it, comes back over. He shows the menu is now working, then exclaims “there! I have proved Paul’s theory is correct”.

No you haven’t, the behaviour is just back to what it was; with the bug we had just been talking about. With the bug that I have a potential fix for; but working on my machine only.

I’m beginning to think William has actually lost his mind. It’s very concerning.

Deliberately Deferring Work

The team was looking like it had failed to fix the bugs they had promised to do. With only a couple of days before the planned release, the managers need to make a decision. They talk about Seth, a Senior Developer who is regarded as one of the best in the company.

“Shall Seth jump in and fix loads of bugs?”

“No, because that will give a false impression of what the team can handle, then we will get too much work in the coming months.”
Team Manager

It’s like when it gets to the end of the tax year, and departments blow their money so that next year, they will get the same amount of budget allocation. If they underspend, then the finance department will likely reduce their budget since it seems they overestimated before.

In this case, we are reducing our commitment so we can keep our commitment low in future months. It might make it easier for everyone to manage, but is terrible for the end-user who has to wait longer for their bug fixes. It’s a really bad attitude to have. We should put quality first. If there are staff available, then use them to improve the quality.

How Many People Does It Take To Design A Webpage?

We have a requirement for a 404 error page.

I asked the Product Owner if we have a design for it. Should be simple shouldn’t it? Probably has a heading, a company logo, maybe some other text.

He posts on Slack that he has had a word with the User Experience team and they are going to design it. Fair enough, although why hasn’t this been designed already? We are several months into a Web-based project.

A Software Architect then replies saying that he has put together some “findings” and will arrange a meeting with other Architects to discuss it.

Hang on! how many people are involved in a simple page design? Why does it need Architects?

The world has gone mad.