Tag: Process

“I did not realise I had to check it in”

Beavis was assigned a fix for a release. We support multiple versions so it needed to go into the “Release” branch (older version) and the “Main” branch (current version). Personally I think it makes sense to make the changes into the Main branch, then merge them into the Release branch. It probably doesn’t make a big difference really, but I told him that.

Beavis decided to ignore me and just check in the fix into the Release branch.

A few days later, one of the Release Managers tells Beavis that his change is missing from the Main branch. 

“I did not realise I had to check it in”, he lies.

Beavis

The thing is, I then check the difference between Main and the Release branch and there’s two other check-ins from Colin and neither of them have checked it into Main.

I don’t understand how we have these developers that have worked here years and they still don’t understand our process.

The Code Analysis Meetings

Our Team Lead had been hyping up how important it is to improve the statistics of our codebase. So we have a report that runs and gives you metrics about duplicated code, “code smells”, possible bugs, test coverage etc.

Colin volunteered to lead on this. I know that he is just trying to impress our manager to try and worm his way into another undeserved promotion. The thing is, he isn’t even thinking about what he is doing.

There’s been 2 meetings per week, and it’s been going on for 3 months. I wanted to know what was going on because we haven’t heard any outcome from the meetings, and the statistics haven’t improved either.

Intervening

I asked one of the attendees if they had discussed a particular rule that was flagged by the report, and told him that if we suppress the rule, it will improve the metrics by 300 or so. He told me to come to the meetings.

So I join the meeting, and ask them to investigate the possibility of suppressing this rule and people seem to think it is a great idea. No one had any other new ideas, so then Colin said we would continue going through the report.

I asked him to explain the process since it was my first meeting. He said there are different severities like low, medium, high, critical, and managers only care about the two highest categories. So he was going through each rule and commenting on them saying they can be changed to Low, or that we need to fix them.

So we start looking at each rule violation, and there’s about 8 people on the call; mainly developers but a few interested testers, and 2 managers. I say “interested” because they have turned up to the call, but when Colin asks people to discuss it, no one can make a decision. Colin kept on trying to describe what the code was doing but made so many mistakes, I had to correct him several times.

I was basically taking over, but kept on asking for other people’s opinions, but people seemed pretty indifferent. The call had gone on for nearly an hour and a developer hadn’t said a word, so Colin accused him of being asleep. The developer said he was awake, but then continued to stay in silence for the rest of the call.

I was told there was another meeting in a few days time, and it would be more technical, so I agreed to join.

The Great Realisation

That meeting was basically the same people, but excluding the managers. Colin continued going through each rule violation again. The conversation that followed roughly went like this:

Me: “Hang on, this is taking forever. We are seeing the same type of rule violation and you have gone through about 15 of them now.”

Colin: “Yeah, there are loads”.

Me: “This seems like it is gonna take all year. How many violations of this particular rule are there?”

Colin: “4000”.

Me: “Hang on, let me get this right. You are going through each of the 4000 violations, analysing the code, and trying to decide if you should mark it as Low severity or not?”

Colin: “Yep”

Me: “Don’t you think it is stupid?”

Colin: “That’s what managers want us to do”

Me: “No, the managers want you to decide how important the rules are, not how important each particular violation is. If they were aware there’s 4000 of the same rule, I’m sure they wouldn’t want you to do this. Why don’t we just look at the rules? How many rules are there that are being flagged as High or Critical”

Colin: “5”

Me: “So you have had about 12 meetings to discuss 5 rules, and you haven’t even gone through 1?”

Colin: “Yeah”.

Absolute waste of time. Just think, if there’s only 6 people and you paid them £12 an hour, and had 24, 1 hour-long meetings that they attended – that’s a cost of £1,728. But then sometimes there would be more people attending, and you had the expensive managers too. What did they achieve until I came along? Nothing. No one questioned it.

The thing is, we are concentrating on the wrong thing. There’s plenty of bugs to fix which bring value to the users. Why are we wasting time tweaking things that don’t need to be changed? The crazy thing is, we are spending all this time talking about doing it, and it isn’t being done.

The Efficient Team

In the next meeting. I told the manager our new approach, and also raised some of my concerns with how much importance we are placing on this. She didn’t care about my concerns so that got ignored. What she did say was “you guys are becoming an efficient team”.

Is that even serious? Months of wasted time. The words sound sarcastic to me, but I think she was being serious; the tone sounded sincere.

So in conclusion: Colin was just trying to impress the managers by taking the lead, and so was everyone else really; they were on the call, but they really had no passion for what we were doing.

Shape Up

A bit of a rarity on this blog; time for something positive.

I have been reading the book “Shape Up” by Ryan Singer which can be downloaded free from https://basecamp.com/shapeup

Book Summary

Shape Up defines the Agile Process that Basecamp utilises. The summary at the end of the book lists their ideas as follows:

  1. Shaped versus unshaped work
  2. Setting appetites instead of estimates 
  3. Designing at the right level of abstraction 
  4. Concepting with breadboards and fat marker sketches (a sketch made with such broad strokes that adding detail is difficult or impossible)
  5. Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time 
  6. Choosing the right cycle length (six weeks) 
  7. A cool-down period between cycles 
  8. Breaking projects apart into scopes 
  9. Downhill versus uphill work and communicating about unknowns 
  10. Scope hammering to separate must-haves from nice-to-haves 

There’s quite a bit of Basecamp jargon in there. Some of the sections I didn’t care that much about, but there’s plenty of aspects that seem like they counter many of the problems I have witnessed when it comes to Agile development. So I think this book does provide answers.

Notes From The Book

Some key points that I liked or found interesting (this is basically me copy and pasting from the PDF):

  • Instead of a traditional two week sprint, they work in six weeks. This time is “long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start”.
  • They “focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend?”
    • Small Batch : This is a project that a team of one designer and one or two programmers can build in one or two weeks. We batch these together into a six week cycle. 
    • Big Batch : This project takes the same-size team a full six-weeks. 
  • They “give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time”.
  • “Pitches” are posted as Messages in Basecamp software. There are five parts to include in a pitch: 
    • 1. Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this 
    • 2. Appetite — How much time we want to spend and how that constrains the solution 
    • 3. Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand 
    • 4. Rabbit holes — Details about the solution worth calling out to avoid problems 
    • 5. No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable 
  • “Before each six-week cycle, we hold a betting table where stakeholders decide what to do in the next cycle. At the betting table, they look at pitches from the last six weeks or any pitches that somebody purposefully revived and lobbied for again.” 
  • Backlogs are big time wasters. “The time spent constantly reviewing, grooming and organising old ideas prevents everyone from moving forward on the timely projects that really matter right now”. Pitches therefore, do not go on backlogs. “If we decide to bet on a pitch, it goes into the next cycle to build. If we don’t, we let it go. There’s nothing we need to track or hold on to. What if the pitch was great, but the time just wasn’t right? Anyone who wants to advocate for it again simply tracks it independently—their own way—and then lobbies for it six weeks later.”
  • “It’s not really a bet if we say we’re dedicating six weeks but then allow a team to get pulled away to work on something else. When you make a bet, you honor it. We do not allow the team to be interrupted or pulled away to do other things.”
  • The “Circuit Breaker”: “We combine this uninterrupted time with a tough but extremely powerful policy. Teams have to ship the work within the amount of time that we bet. If they don’t finish, by default the project doesn’t get an extension. We intentionally create a risk that the project, as pitched, won’t happen. This sounds severe but it’s extremely helpful for everyone involved.”
    •  it eliminates the risk of runaway projects
    •  it means we did something wrong in the shaping
  • Dealing with bugs
    • Use cool-down – the two week gap between the six week cycles
    • Bring it to the betting table – plan it into the next cycle
    • Schedule a bug smash – dedicated time usually around downtime like Christmas

Personal Comments From My Experience

So some discussion on why their approach is good:

  • I found with 2 week sprints there’s a lot of meetings involved for only 10 days work. You end up spending half a day planning, then there are 1 hour meetings like the “Retrospective” that happen at the end of the 2 weeks. With all these meetings, it cuts into the 2 weeks. 6 weeks makes it seem like the planning is less frequent and more worthwhile. You have more to praise/criticise when you reflect on your team’s progress during the retrospective.
  • Sometimes important bugs become the priority then you end up shelving your work. It would be nice to have the intense focus to ensure you finish what you start.
  • When we get to the end of the sprint, it is too easy just to move the work into the next sprint, so it makes the 2 week block seem meaningless. Knowing the timing is stricter will put more focus on actually delivering.
  • Often, bugs that you think are annoying are deemed low priority so they get shoved on the backlog and never fixed. First of all, it would be good to have the freedom to fix bugs that personally annoy you. Secondly, what is the point of having a backlog if it’s just a list of work you know no one will ever address. 
    • “Is this bug logged?”
    • “yes, it was logged 3 years ago”.
    • “brilliant”.

Arguments on the Major Incident Call

When a serious bug is found, there’s all kinds of managers that have a call to discuss it, along with some representation from Development – so at least one Developer and preferably a Tester too.

I got asked to join the call, and there’s like 8-10 people on this call. The representative from Support has roughly described the bug, and how often it has been reported.

Then there are a few managers bickering if the Major Incident is a Medium or High severity. The thing is, we all know it needs fixing urgently, and from my point of view, it doesn’t matter what severity they actually give it. Maybe the managers care because it depends who they have to notify and follow a different process. 

I just know that I need to fix it as soon as I can.

However, while the call is going on, this is time wasted because a developer isn’t looking at it. I had been told there was a bug in a particular area, and I know I’ll be the person trying to fix the issue, but I cannot start because I’m on the call. I could multitask, but I wasn’t given the stack trace or recreation steps, so I was left waiting. It would be hard to concentrate if I was half-listening to the call too.

I think that meeting went on for an hour, which is an hour lost. It should have just gone straight to development, then argued about the trivial details whilst it is being looked at. They had further calls anyway for updates, so they could have had better updates from the development team. 

At that point, I may have been able to tell them:

  1. When it was introduced
  2. What caused this change in behaviour
  3. How serious it is – does it affect other areas that haven’t been reported yet.

So they basically try to discuss things they know nothing about. Ideally, they just need an initial meeting with the “stakeholders” to bring attention to the problem, make sure people are assigned for responsibility/accountability reasons, then arrange a time to reconvene to discuss further.

Remote Standup Meetings

We have a daily “standup” meeting where each person in the team says what they did yesterday and what they are going to do today. You can also highlight any “blockers” that will prevent you from completing your work.

Since we are all working remotely, we just do them using Microsoft Teams. At first we just nominated someone to speak next, but since we have around 10 people in the team, and people don’t really listen or pay attention, then we ended up with people asking: “has everyone been?” – when only half of the team has been.

When Microsoft Teams introduced the “Raise Hand” feature, we used it as a flag to show who still needs to talk. Still, Colin says “who is next? Matt have you been?”. Yes he has been, why don’t you choose one of the 6 people with their hands raised?

Another point which illustrates that people don’t listen, is when I say something like “I’ve sent a Pull Request for my work but no one has reviewed it yet, can someone review it?”. Then three hours later, no one has reviewed it.

I think the problem is often that people are so focussed on what they have to say, then they don’t listen. I was watching a video about it and the guy reckoned the “walking the board” method gains more attention. This method is where you look at your “Kanban board” which shows you all the work your team is doing. Then you can go through each item in turn, and the relevant people can then speak up. I still think you’ll have the same problem since you know that you will have to speak when it gets to your work.

There are a couple of people that seemed to nominate people without even looking at the attendees, so then they end up in embarrassing situations where they say “Rob can go next”, but Rob isn’t actually on the call. Sometimes it was well-known that they don’t actually work that day because they are part time. 

We also have someone in our team that just deals with Test Environments so isn’t directly involved in our work. We did raise the point that it is stupid for him to attend the stand-up meetings but our manager said he wants it to continue so he feels part of the team and also gets to hear the team talk. I guess that is a good point – since we are at home, we don’t get to hear our colleagues speak much.

His updates are so boring, and he delivers them in a really bored tone. I often think he doesn’t have much work to do, so just says words to blag it:

  1. had to restart some servers, and upgrade some RAM.
  2. signed off some policies, and am looking at patching some security vulnerabilities.
  3. I sat down with Dan for a bit and went through some tickets. Got some other tickets. Need to review some policies. Still need to complete some security vulnerability patches.
  4. Busy doing environment stuff, mainly security updates which I’ve almost finished. Just need to do some Virtual Machines today. There’s about 40-50 clients so that’s going to take the full day, maybe tomorrow as well.
  5. Catching up on comms, am currently resetting a password, and then gonna look at some more environment tickets.

How long does resetting a password take? Is any of that actually useful to the team anyway? He may as well just say “Environments stuff” then choose the next person.

Another thing that always happens is when you pick someone to go next and you are met with silence. So you say “you are on mute!”, then a few seconds later “oh yeah, sorry I was on mute”. Here are some classic “mute” scenarios that I wrote down:

Becky: “Good morning Colin”
*few seconds of silence*
Colin: *bland tone* “good morning”
Becky: “You sound down, Colin”
Colin: “I said ‘good morning’ but I was on mute, so that's my second attempt.”
James: "Can everyone see my screen ok?"
*silence*
Becky: "yeah, sorry I was on mute"
Colin: "yeah, sorry I was on mute"
Matt: "yeah, sorry I was on mute"
Matt: "Colin, have you been?"
*silence*
Matt: "You still have your hand up"
*silence*
Matt: "you are also on mute"
*silence*
Colin: "I'm on mute? how did that happen?

And a bonus scenario:

Becky: "this meeting has started early!"
Colin: "who started it?"
Matt: "it was you Colin"

Report Ideas

Our Team Lead had been hyping up how important it is to improve the statistics of our codebase. So we have a report that runs and gives you metrics about duplicated code, “code smells”, possible bugs, test coverage etc.

Our Team Lead said that Colin had some great points and would be presenting them in our meeting. 

​and Colin’s points were

  1. Can we add rules?
  2. Can we remove rules?
  3. Should we document our changes?

​Which are all basic questions and not any kind of guidance. Obviously, the answers are 

  1. obviously, 
  2. obviously, 
  3. and the majority of the time, no; that would be overkill

He also did a demo to illustrate what we can include in our documentation. The “code smell” was that there was the same assignment twice like:

somethingEnabled = whatever!=null && somethingElse!=null

otherFeatureEnabled = whatever!=null && somethingElse!=null

So the assignment logic is the same. Then he said the solution is to create a new variable. Yes, that is obvious….  but he has some timing tests to illustrate the performance difference of 0.00025 seconds. Since he has proven that this is the correct thing to do, we now must document that as the official solution.

Embarrassing. So cringey.

Then the next day, Colin was talking about his work item and said if he has permission, he would also fix the “code smells” that were declared by the reporting software. So the Team Lead asked him what the “code smells” were and Colin said “unused using statements”.

Since when did developers ever declare/ask for permission for something so trivial? We just did it because it’s obvious. Even Visual Studio tells you to do it. “Unused usings” are shown in a lighter font, and you have an icon in the side prompting you to remove them. It’s part of the Code Cleanup feature too, so you run it and it automatically removes them.

Any developer would just do these refactorings as standard. 

There’s a general rule called DRY; Don’t Repeat Yourself that means you should avoid duplicated code. We don’t need to document that any further. 

Other code smells like extra blank lines, spelling errors, unused methods; are all trivial. You don’t need to explain them. The reporting software actually has explanations and examples for all the rules anyway.

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:

  1. Use GitHub for source control
  2. Take advantage of side-by-side diffs, and publish feedback in this code review process
  3. Use Jest for Javascript Testing
  4. 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?

Duplicate Wikis

Our repository has a ReadMe with some instructions in it. We also have 2 sub folders each with a similar ReadMe. We also had a team documentation website where similar instructions were pasted in.

I raised this with my team that if you want to change an instruction, you have to paste it in multiple places and it’s a bit silly. I did try and simplify it somewhat by reducing the amount of information: Just by using hyperlinks to direct you to where the more detailed information was.

I took some annual leave, and when I came back to the office, I found that we now have a GitHub Wiki and the ReadMes are closer to what they were before (my hyperlinks removed), but now with even more information on them.

Additionally, there was a Pull Request from a team member to update the main ReadMe with some incorrect information. I point it out to them, and they say “I pasted it in from the other ReadMe”.

Well, this is exactly why we don’t duplicate information, and why I raised this as an issue to the team.

If this was code, and not text, I know they wouldn’t do it. If you write some lines of code inside a method and need it elsewhere, they wouldn’t copy and paste it like a Junior may do. You would just reuse the method by calling it directly. If you copy and paste, then change one file; then there is a difference in behaviour and a Bug is introduced.

Since we are talking about text, you shouldn’t copy and paste it, you should use a hyperlink. Then you can just change the main source. Then there are no conflicting instructions. 

Always have one source of truth.

This is what I did. Why was it undone?

The Password Reset

Our IT department was configuring a new Laptop for me, and they contacted me stating they need to reset my password so they can do the final stage of the set-up.

Seems like a terrible process to me. Why do they need to impersonate me to configure a Laptop? Surely their privileges should be suitable to do their work?

I try to carry on with my work, but after my machine locked, I tried my new password but it wouldn’t let me in. I tried my old password and Windows accepted it, or at least initially. I then got the pop-up balloon that stated Windows needed my new credentials. So I locked my machine, tried to log back in, and Windows said I was locked out.

So I called IT and they unlocked my account but I still couldn’t get in. The IT guy said he would reset my password again. For security, he said I needed to state my line managers name. I said Alan. He said it was wrong, it is Louise. I said I had switched a few weeks ago. He reset my password.

There’s a couple of things wrong with this approach. I know quite a lot of people’s line managers, and this is information you can look up inside the company. So if someone is off on annual leave, I could ring up IT pretending to be my target, ask to reset the password, state their line manager’s name, and there you go; I have access to their emails and can do whatever I want under their name.

If I was an external attacker, I might not know their manager, or maybe I would have old information and could tell them their old manager. The IT guy should have just said I was wrong, and not tell me what the answer is. Anyone could say “oh yeah I’ve switched managers and your system is wrong”. Even if he did refuse to reset the password, I could just call again with the new information.

Why would you do something as major as resetting a user’s account when the supposed user got a security question wrong about themselves?

People Not Actioning Pull Requests

I always think Code Reviews (or Pull Requests) are very important, but there seems a lot of people don’t seem motivated to actually do them.

I’ve complained to my team members for not engaging with Pull Requests. We say that we need 2 approvers before code can be checked in, but yet only 2 people (other than me) do them within a reasonable time, and there are 7 of us. So if someone is on annual leave, then the Pull Request is more than likely gonna stay there in limbo.

After complaining on two occasions, Sean finally completes one within minutes of one coming through. “Brilliant!” I thought, my words have finally got through.

I had a quick skim through the code and I was concerned about how many Unit Tests had been temporarily removed. Yet, Sean hadn’t actually flagged that up in his comments! He had overlooked such a blatant error.

The comment Sean left on the unit tests was: “no new line at the end of file”. That’s such a trivial thing, and GitHub actually flags that up for you anyway. There were some other comments on other files where Sean claimed that the “Code Analysis would flag these lines up”; however the developer hadn’t even changed these lines. The report wouldn’t have complained about them.

So he made a redundant comment, and some incorrect comments, and overlooked the massive problem that the developer had actually removed some tests. Presumably because his new changes broke existing functionality. It was definitely not ready for Code Review. It gets a good old “Needs Work” from me.

Maybe some developers just aren’t good at looking at code…