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?

Using Instructions To Make Instructions

William contacts me and says he is reading our instructions of how to deploy an application and there’s some parts he found hard to follow. Which is weird because his team had made several apps, and this wasn’t an issue then.

So I asked him what he is trying to achieve. He says that he is planning on “putting together some instructions for other teams to follow”.

Sometimes I think William is just in my imagination because these situations are like an unbelievable, comedic character. This isn’t “The IT Crowd”, or “The Office”; this is real life.

He is trying to write instructions on how to deploy an application by… reading some instructions on how to deploy an application.

They have already been written. I wrote them, for this very purpose. He is reading them, and plans to write some himself. Why?

This is literally insane.

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.

The Junior Contractors

Recently, we have hired a bunch of Junior developers via a Bootcamp company. This company basically takes people on an intensive training course, then they find them work. So they are essentially a contracting company, but are sending out fresh-faced developers to their first jobs. Let’s refer to them as Training Company.

As far as I understand, the intention is to hire them permanently, but my company is prepared to pay the premium for the Training Company to educate them.

I think to preserve their own interests, the Training Company give them assignments/exams to complete. This way they can understand how good they are and quickly reassign them if they are let go by their current “employer”.

So for the past two weeks, these Juniors have either been studying for an Agile exam, or writing an essay based on work they completed, but they are doing it in company time, not in their own free time.

So the way I see it; they are getting paid by my employer to do work for the Training Company… with the Training Company pocketing a fee.

They are completely mugging us off there.

Yet, if the intention is to employ them permanently after the initial contract; then all these assignments the Training Company give them are pointless. Unless of course, you can prove that these assignments and exams are actually beneficial.

One of the Juniors comes back from the exam and says they have failed. They then go up to their line manager and say “was that a retrospective I led last week?”, the line manager brutally replies “no, it was a refinement session; that’s exactly why you failed”.

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.