Colin said that our Sprint Burndown chart wasn’t accurately reflecting the work done. He said we were overrunning with each Work Item which meant that we would have 0 points for one Sprint, then we get the full value in the next Sprint – which shows as a sharp drop on the Burndown chart.
I told him that’s how the Burndown charts work – but he said they want more accuracy. I argued further: If the requirements haven’t been met, then it’s not complete, so you haven’t added value to the software – i.e. you have made no progress.
A few days later, our Scrum Master had been in a meeting with him and was instructing us on his new process. Colin’s idea apparently was to add a “task” for each day and link it to the Work Item. At the end of the day, you mark the task as closed.
I’m like “eeeeeeer wut”. So now it tracks your daily work.
I told her she must have misunderstood. Adding a task per day is just counting the amount of days in the week. I suppose if you take a day off, then you won’t count that day.
I questioned it, and she agreed that it didn’t sound right. So she goes back to Colin. No, he really does want a closed task per day, but also said to create a task even if you are on holiday.
Wut.
add tasks to all the things!
So they want effort more accurately tracked, but are now just counting days, even the ones you haven’t worked. Surely if you create a chart, it’s just gonna be a diagonal line with no fluctuations.
What are we supposed to write for the task’s title and description? “Carried on working on it 7.5 hours”.
I just refused to do it, but the Scrum Master did the admin on my behalf. The idea lasted about a month.
I find that Burndown Charts often look unclear anyway. Here is one from another team:
So what are we even seeing here? The chart to the left shows Tasks, although the chart doesn’t seem to show the correct Completed figure – it shows as 0%. However, you do see the average is 46 which I think is per day – which illustrates the ridiculous number of tasks that teams were creating anyway.
The chart to the right shows User Stories but I think it’s not the number created, but the total points assigned. So one might be worth 1 point, but another could be worth 8 – it depends on how complicated the work is. I think this is a typical Burndown where the first few days nothing is complete because the developers are working on fixes, then the tester will get it in a few days. In the second week, more items are completed. There were even 4 points removed, presumably a change of requirement or maybe it was deemed redundant.
This is another chart that a team posted to boast about their progress. This example is a bit more unclear, but I noticed the Tasks Burndown (start 12th September) is not for the same time period that the Stories Burndown is (start 29th August).
The Stories Burndown looks interesting doesn’t it? It looks like only a small amount of work was done and then when it gets to the end of the second week, they add even more work. I did theorise that maybe they didn’t officially start the project until after 10th September but what does the 72% Completed mean? That seems to imply they are ¾ through their project. ¯\_( ͡° ͜ʖ ͡°)_/¯
A Product Manager recently wrote about how Software Bugs aka Problems are prioritised, so I thought I’d share that here.
Prioritisation Spotlight Report
Product Managers conduct a weekly meeting with other stakeholders to discuss Problems and their effects on our customers. A key output of this meeting is to ensure that we are prioritising the defects that are causing our customers pain or have the ability to do so.
These Problems can range from being the result of a major incident, recent software upgrades, or internal database monitoring. However, what they share is that they all have the ability to generate customer dissatisfaction.
The Product Managers have been ensuring we are able to accurately and consistently apply logic to the Prioritisation process. This is a key requirement of the Problem review that allows us to create the prioritisation for Development to work on.
How does this work?
The weekly Problem Prioritisation meeting is open to anyone who has a business interest in resolving these software defects for our customers. When discussing these defects as a group, a number of areas are covered, some of the new key areas are below:
Number of cases linked to Problem – this is multiplied by 2 so a Problem with 4 cases will generate a score of 8 for example
CSAT (Customer Satisfaction score)– This is the level of market impact the defect has, or is expected to have, and is scored in 4 areas; Critical, High, Medium, Low.
Software upgrade blocker – Does this hold up the ability to patch customers to a newer version of the software
Safety rating – Does this have safety implications?
The Prioritisation reason – has the problem been raised as an internal escalation, safety, Information Governance, Security, Customer pain/Escalation, Service Level Agreement, or an Enhancement via the User Defined Roadmap.
IG – Does this have Information Governance implications?
Number of users impacted – taken into account based on how widespread the issue is and how many customers are affected.
What will this allow us to do?
This is going to help us all become aligned with the vision across the different areas of the business and will enable key stakeholders access to a single source of truth when scoping these items into the team’s backlog. A “Top 100 Problems” list will be updated after the weekly meetings.
Many years ago, I was listening to a podcast where a group of women were talking about their experiences in Software Development. I think Person A had started their own company so now didn’t do much development because they were now the CEO. Person B had switched to teaching software development and was going to take up a role as a “Developer Advocate” which I think is kind of a teaching role; making tutorials and promoting via social media. Then Person C seemed happy being a software developer.
In other blogs, I’ve briefly mentioned my observations with women in software development. I find there’s a much higher percentage of women that will desire to go into management, whereas many men seem to love the idea of a career constantly coding.
I’ve followed a few of the women from the podcast, intrigued where their careers would go. Person A and B are still CEO and Developer Advocate, respectively. Person C, who was happy being a software developer had apparently got their dream job at a big tech company early 2021.
“I’m so lucky I get to do something I love for a living”
Neary a year later, they announce they are taking a year out due to maternity. A few months later, they state how being a new mother has given them new inspiration as a software developer. I wasn’t sure if she had been coding in her free time, or was just posting for attention.
She claimed that she could:
“tap into new-found inspiration and creativity”
“think about more nuanced edge cases”
“Be more efficient”
“better at asking for help”
“better at asking the right questions”
The justification was that you have extra accountability, have to maximise how you spend time/money, ask for assistance when you struggle to support your child. It was quite tenuous and when people asked her to elaborate on how it really helps coding, she just accused them of “toxic masculinity”.
Only 2 months later, she announces that she applied to switch roles to become an Engineering Manager. Wait, what!? What happened to all that boasting about securing her dream role at her dream company? What about this new-found inspiration to be a better developer?
How can that mentality shift in such a short space of time?
“I kinda just fell out of love with coding”
People often say that social media gives people a skewed perception of people’s realities, because it is a filtered view: people only post the good stuff, and sometimes even modify the photos. If someone goes on holiday, you see the beautiful sunny beach, and the exciting scuba diving session. You don’t hear about the argument they had with their partner, or how they were bedridden with illness on the other days.
So was she lying about her love for coding? Were the development teams at this company not well suited to her mindset or ability?
When she did return from maternity leave, she then said he loved being a manager “way more than I liked being a software developer.”
I do find it odd that her mentality has always seemed to be focussed on promoting women in tech, and calling out “bro culture”, but then she has ditched being a developer and followed the stereotype of being a manager instead.
It’s been a while since we organised a “Bug Bash”. The general idea is to focus on fixing software bugs and clearing the seemingly ever-growing list. Sometimes managers have organised this as an optional thing over a weekend, or sometimes opted for a work week.
The problem I have with this idea is that with a strict deadline, you are encouraging people to rush. If you want to follow the usual process of a developer really understanding the bug (reading the bug report carefully, recreating the issue, analysing the code, coming up with a solution, testing it manually, maybe writing some unit tests for it), then going through the code review and testing process – then you are being really hopeful that it can be done in such a strict time-frame.
I find another developer will always have some opinion on your code, so you make a change, have to retest it and then get them to review it again. Then when coming to patch it on the test environment, you then might get problems with the build server or the test environment.
So the only bugs that are really appropriate for a Bug Bash are ones that are easily recreatable, quick to fix, and low impact. All the true high priority issues will have been addressed more urgently and put into the normal release process anyway.
What you have to bear in mind, is any change has some kind of risk that you might introduce another problem, and this increases when you try and rush the change out; which is what the Bug Bash inherently prioritises.
I was looking for an example of how managers sold the idea, and I found one that actually seemed a bit more thought out:
Next week we are to down tools on project work and spend the week stabilising our product.
Service have provided a list of 300+ issues they would like us to work through. In addition, Paul has been reviewing the Error Logs to identify the most frequently reported errors and is creating items for these.
The domain experts are currently reviewing the list and identifying the issues they feel can be fixed next week. These will be placed into the Stabilisation list.
The priority order for working these items is set by a temporary field ‘Bug Fix Priority’. 1 is the highest priority.
Each developer should select the next bug at the top of the list that is not currently being worked, change the state to Assigned, and Owner to themselves.
All Priority 1s must be completed first. If there are no defects you are comfortable fixing, please speak to me before moving on.
Each bug fixed must have supporting unit test(s) before being sent for code review.
At no point should a developer have more than 3 items they are involved with, this being 1 bug being worked on, 1 being code reviewed and 1 with the tester. If you’re waiting for a code review - go chase it. If you're waiting for a test to complete – go help out.
It is important to note the emphasis on this release is QUALITY.
With this in mind, the attached spreadsheet has been produced that maps a developer to someone who will review their code and DB changes. Where possible we have also mapped each developer to a test resource. The developer and tester jointly own the end to end process for each bug.
A kick off meeting will be held at 10am on Monday in Room 1 for all to attend.
Code Reviewers will hold daily stand-ups with their development and test resources which will then feed into a management review at 4 pm.
Darren
Development Manager
So, they have allocated a full week, tried to analyse the bugs to see if they are suitable to fix quickly, and they have emphasised it is about quality. However, they seem fairly strict on the order the bugs are addressed, so you may end up with developers being forced to pick up items in areas they don’t specialise in.
There was a follow-up email stating that there were issues with the build server which caused them to lose time.
All,
The plan is to finish coding tomorrow to allow test to complete on Friday.
With this in mind and as a result of build issues experienced yesterday we’re considering the possibility of overtime tomorrow evening to make up lost time.
Can you please indicate using the voting buttons by 12pm tomorrow whether you’d be available for overtime tomorrow evening.
We'll be ordering Pizza and a Beer too, to keep us fuelled 😉 It would be very much appreciated if you could stick around. Every bug fixed is giving our end users a better customer experience!
Thanks,
Darren
When Bug Bashs have occurred over the weekend, I think Developers and Testers have started at the same time, but they wouldn’t have had anything to test until mid-day at least – due to development time, code review time, then build and patch process. So the Testers will just be earning money for chilling out and eating pizza.
I found an instant messaging conversation with a colleague about a different Bug Bash:
Daniel 11:37:
one of the bugs on the list to be fixed in the bug bash was logged by me 5 years ago
so very urgent then
Me 11:38:
the bug bash isn't supposed to be for urgent issues
Overtime requests will only be approved for time spent on defects that are Fixed, Tested, PO Approved and Closed(Done)
So you could do some complex work, not get it done, and therefore not get paid
Daniel 11:42:
yeah I read that today
who's going to go for that
it's completely the wrong way to fix bugs
So this bug bash seemed to be for clearing down all the bugs that have just been ignored for years. The problem with old bugs like that is that you could spend time trying to recreate them, and find they are now obsolete due to other code changes, or obsolete features. The managers also decided they didn’t want to pay people for incomplete items, so you cold spend ages working on something and not get paid.
You could close the bug as obsolete – it’s not fixed so you don’t get paid
You could spend ages recreating it, coming up with a fix, but there’s not enough time for the rest of the process to actually complete it.
You could come up with a fix, but there’s a small bug found by the tester. You could persuade them to keep quiet so you both get paid.
You could come up with a fix, but build issues cause it to not get tested.
I think that every-so-often, you do need to analyse the list of bugs you have, and try and clear it down; either by fixing them, proving they are obsolete, or maybe just marking them as never intending to fix. A dedicated period of time is required but I would have thought a 2 week period is required at minimum in order to not cut corners.
We used to have a very large support team in our own call centre. As a software developer, we were occasionally sent to go talk to them from time to time, and I was amazed at how busy they were. Usually, as soon as they had put the phone down, they had another user call up.
Sometimes it was that the user just didn’t know how to use the system, and other times it was to complain about a software bug or slow performance. The call centre staff were rapid at entering the information into the system, and were brilliant in asking the user the right questions to really understand their problem. They could often tell the user if the issue was logged or not, and also give them some relevant work-arounds.
After speaking to some of the staff, they explained how strict the culture was there – they were monitored on how fast they picked up the phone, how long the call was, and how many breaks they had. They said how annoying it was to be warned about being late when it was due to bad traffic.
It surprised me because it seemed a completely different culture to how the development department is run. We are flexible when we start; so you can just turn up late and no one cares. We were never challenged on how long our work took to complete. I guess if our work is poor quality, it’s the call centre staff that took the complaints!
At some point, some manager decided to use a 3rd party company for Support, and most of our Support staff either left or (presumably) got redundancy.
The amount of complaints seemed to go up on various social media platforms, and I got the impression this 3rd party company didn’t know our software so were just providing users generic statements from a script “can you try turning it off and on again?”. Maybe if they got past the initial questions, they then got put through to our smaller 2nd-line Support team.
A few years later, I think a new manager came in and decided to try to reverse the decision, but it’s going to take a bit of time to get the new staff as good as the old ones.
“As part of our drive to strengthen our customer satisfaction and experience along with simplifying our ways of working for both our customers and the service desk, the decision has been made to insource the call centre. All calls will now come directly into the service desk.
We have already run a couple of trial switch offs over the last fortnight and the initial feedback has been unanimously positive with customers preferring to be directly connected to the service desk; just in this small sample there has been an increase in both the quality of cases and first-time fixes. We will continue to invest in developing a world class service desk.”
Company Announcement
It seems obvious to me if you make the support more generic, then it’s going to decrease customer satisfaction.
The only problems I had with Support is:
A) when they would link completely different issues to the same bug report. Sometimes you see that a bug that you thought should be super rare – has had 100’s of reports from the users. Then when you look into the cases, you see that 90%+ of them are unrelated. We could have probably put some advice on how to decide if issues are the same root cause or not, in order to try to help remedy this.
B) Sometimes there’s other data entry errors that end up being misleading, like this:
Support (in the free-text description):
"however we have been able to re-create this on the test system by"...
also support (in the mandatory fields):
"Recreated in-house: No
Reason not recreated: Unable to recreate"
I remember the days of being a junior software developer where you write code because “it might be useful at some point in the future”. The thing is, this means you end up writing way more code than is necessary, and could lead to overcomplicated designs.
There is a concept called YAGNI: “You Ain’t Gonna Need It”
Swizec sums this up well here with a strong hint of sarcasm…
And that brings us to the other YAGNI: Building stuff you think you’ll need before you need it.
You think of a wonderful abstraction. A wonderful little feature that’s gonna help oh so much in the future.
You build it.
Months pass. You tweak the code here and there. Nobody’s using it, but you have to maintain otherwise it’s gonna break. Whenever you implement a feature, you have to think about how it impacts this code you’ve got.
It’s slowing you down. Making you think. And you aren’t even using it.
But one day! One glorious day, your PM gives you a task. A task from the gods. You are about to use this code you predicted 6 months ago!
You are a god of prediction! You knew it all along!
public static bool IsModalDialogOpen()
{
Boolean isModalDialogOpen = Application.AnyModalDialogOpen;
if (isModalDialogOpen)
{
throw new DialogException("A dialog is already open");
}
return isModalDialogOpen;
}
So they have written a method that checks if a dialog is already open. If there is, then an exception is thrown (depending on their error handling, it would either crash, or display some kind of error to the user), otherwise it returns false. Since this is new code, the only places that called this method was in his new code. However, he never checked the return value of the method. Since it is defined as a Boolean/bool then it could only return true or false, but his logic only ever returned false… and all the calling code never used the value. Our exchange went like this:
Me: Why do we have a return type for this method when the return value is not used above?
Developer: If any one in future want to know the value it will be useful because of that I have added.
Me: https://rules.sonarsource.com/csharp/RSPEC-3241
Also: it will never return true
Developer: OK, removed the return type.
Me: It needs an appropriate method name now
So at first he says it will be useful in future – which is definitely false – YANGI definitely applied in this situation. Then when he agreed that the boolean value wasn’t useful, he left the method name as IsModalDialogOpen which implies it should return a boolean. In the end, we were left with this:
public static void ThrowExceptionIfModalDialogOpen()
{
if (Application.AnyModalDialogOpen)
{
throw new DialogException("A dialog is already open");
}
}
In another recent change, there was this humorous exchange between two Senior Developers, George and Paul:
George
This looks like dead code...
Paul
Yes on the off chance it was used, we now redirect to the new stored procedure
George
How did you test it?
Paul
We spoke to the Data guys and they said it wasnt used, so no testing required. I am sure.
George
So you leave it in case it is used, but don't test it because it isn't?
Paul
Yes sort of. In case this was ever ressurrected the change was there for them to use
George
It won't be
So Paul had been migrating a database “into the Cloud”, and so went through all the features where that old database was used. He found some old code which he believed to be obsolete, but made the change there anyway. George then flags it up, and Paul says he changed it just in case it was actually used, even though other developers also agreed it wasn’t used. He didn’t test it because it wasn’t used, but the code is there if someone decides it should be used, but it might not actually work because he never tested it.
You could make a variation on that Swizec quote at the start of the blog. It’s extra code that you have to maintain and slows you down, but the day that code is finally used; Paul has saved people time! (Apart from all the developers who will end up looking at the obsolete code in the meantime).
The recent Elon Musk $44 billion takeover with Twitter is causing quite a drama isn’t it? One of those classic takeovers where somehow you are allowed to essentially purchase with money you don’t have and slap the debt on the company you just bought. It really sounds like Twitter was managing their finances in a fairly reasonable fashion, and now their situation seems perilous.
One of the first things was to cut the staff dramatically (~50%). That struck me as an odd thing to do. I understand companies can slowly expand over time, and if they actually thought about it – they could probably trim a few staff positions here and there. But mass-scale redundancies? it’s not gonna work is it? At any company, surely 90% of the people there are required for the business to function.
The problem that many managers don’t think about when making redundancies is that:
You are taking away the culture that got the company where it is today.
You are removing people’s friends.
You are taking away job security as current staff feel that they may be next to go.
The thing is, he also said that remote staff now need to come into the office, so the remaining staff are going to be very disgruntled. This means more people will leave voluntarily. Now he will have paid loads of people to leave, and now need to pay money to start hiring again. It doesn’t really save money, and if it does; it is small figures really; Elon needs to recover billions – not a million.
According to games journalist Jason Schreier, redundancies were made in mistake, and others were made before managers realised their roles were necessary for the business to function.
After cost-cutting, the next thing on Elon’s list was to try to increase monetisation. He decided that the blue verified checkmark was worth $8 a month.
One of my colleagues did mention it, and said he didn’t realise why people were so obsessed with a tiny image, but I explained it helps prevent impersonation. It’s easy to spread misinformation, make slanderous claims, or run scams when you can just change your picture and name and pretend to be another person or another company.
It was no surprise when it happened, you had plenty of people demonstrating this as soon as possible. You had Nintendo of America showing Mario “flipping the bird”, people impersonating Elon Musk, former presidents reminiscing about killing innocents… you name it.
The verified brand situation is getting out of control. Quick thread of twitter blue brands, and brands who might be pissed off at Elon right about now. pic.twitter.com/bZ9PSqZKtf
— Read Jackson Rising by @CooperationJXN (@JoshuaPHilll) November 11, 2022
Loads of examples if you view the thread on Twitter
and therefore, it was no surprise to see the feature currently suspended…
Twitter has suspended the launch of Twitter Blue and is actively trying to stop people from subscribing “to help address impersonation issues,” per an internal note.
Zoë Schiffer
NEW: Twitter has suspended the launch of Twitter Blue and is actively trying to stop people from subscribing "to help address impersonation issues," per an internal note. 1/
“Chesterton’s Fence: Reforms should not be made until the reasoning behind the existing state of affairs is understood. How applies to software: Before deleting code, figure out why it was added.
Other examples:
– Don’t delete a test before you know why it was added.
– Don’t delete a file until you’ve proven it’s unnecessary.
– Don’t make fun of a developer’s old code unless you understand the context in which it was written.”
Corey House
My own Twitter examples:
don’t takeover a company without having a solid plan of what to do with it.
don’t sack staff without knowing what role they do
don’t change the verification feature when you haven’t understood why it was added
Despite this being about software, I think a lot of this applies to Nintendo’s failure of the Wii U (hardware). I’ll first list my notes from the video (I did actually write some notes, then realised he had a great summary in the video’s description) then apply it to the Wii U in the last section.
#5 – Focusing On Current Customers
“It’s tempting to focus on what current customers of the product have wanted at the expense of New customers. If the goal of a redesign is growth, it makes sense to do market research and look at the product with an open mind. Do new customers have completely different needs than current customers do? You don’t grow if you just convert the same customers over.”
#4 – Trying To Include All Features Of Prior Version
“Many companies spend too much budget and time trying to design a product that does everything the prior product did. A redesign is the perfect point in a product’s life cycle to look at it with a fresh set of eyes before making a reinvestment. Throwing off the shackles of the existing product’s feature set might be exactly what your team needs to envision a dramatically more compelling, simpler, and better product for the market.”
#3 – Budgeting Too Little For Marketing
“As a digital software product becomes more established, many teams focus too much on the engineering side of the product. Is it possible that you might be better off budgeting a larger percentage of the investment in the redesign towards marketing? If you’re not doing Facebook advertising, Google Adwords, or Instagram posting to reach today’s audience you could be missing out on an extremely effective way to reach customers that you used to via a different source.”
Companies can often try to piggyback off the previous product’s prior success. They may also have competition so need to advertise to strengthen the brand.
#2 – Failing To Consider A Rebrand
“Though the benefit of an existing brand name and marketing message can be an advantage, depending on the age of your product and the needs of new customers, it may make sense to rebrand. This allows a team psychologically to detach from the prior product more wholly and look at the new version through a completely different lens. Might this be a strategy your company could use to bring life back to a product that’s no longer as compelling and exciting for the market as it once was?”
If you keep the name, you get brand recognition and don’t risk alienating current customers.
However, if you want to move into a new market, you may need a new name to grab their attention, or adapt to a changing market.
#1 – Failure To Establish Measurable Outcomes
“The biggest and most common of the software redesign mistakes I see made is unfortunately the failure to truly establish easily measurable outcomes for success. As a project gets underway, unless design decisions were made to accomplish easily measurable goals, it’s easy for the team and management to lose sight of the purpose and simply look at the redesign as a “project” to be completed. It’s a huge opportunity to reach some exciting goals for everyone, and it provides cause for celebration to all those who were involved as they discover what the market wants!”
Get early feedback on the core product. Before you double-down on investing in the better experience, we need to make sure that everyone across the business has measuring goals so you know that you have reached your growth goal.
Wii U
Focusing On Current Customers – The Wii was a massive success in terms of sales numbers, but I think for most people, they only played a few games and then lost interest. This made the customer base an interesting one. Hardcore Nintendo fans are the ones that bought loads of games, but the casual audience is why so many consoles were sold. For the Wii U, Nintendo wasn’t really sure who it was for. It could play the old games but also had this tablet (“GamePad”) controller. The Wii’s appeal was the motion control remote and minimal buttons; which meant it was easily understood and had mass appeal.
Trying To Include All Features Of Prior Version – By supporting all the Wii controllers as well as the Wii U Gamepad and Controller, it was a bit of a mess with all the options. When playing Wii Fit U, some games like the climbing required a balance board and 2 Motion Plus supported remotes, then after you finish, you pick up the Gamepad to navigate the menus. Then you might go to Boxing, which wanted a Motion Plus remote and a Nunchuk. Way too fiddly and added to the confusion of what you even needed when purchasing the games.
Budgeting Too Little For Marketing/Failing To Consider A Rebrand – They focussed too much on piggybacking on the massive success of the Wii brand, but people then thought it was just an add-on to the Wii. There was minimal amount of advertising so they definitely failed to not only get the message across, but many people just didn’t even know it existed. I even saw Billboard adverts for games such as Assassin’s Creed 3 which had the Xbox, Playstation and PC logos, but no Wii U. No idea if Nintendo had to pay to slap their logo on there; but it can’t help when even 3rd Party companies weren’t making it known the console existed.
Failure To Establish Measurable Outcomes – Don’t think I can comment on this one, but people thought the Wii U was rushed out for Christmas without much of a plan. Many games got delayed so there was barely anything to play in the first 6 months, and the operating system was so slow, even the “day one update” took several hours to download. It was like they just saw it as a “project to be completed” and didn’t think about how players would react to a lack of games, and a long wait to even get them to load (it took several months for Nintendo to fix the slow operating system).
I haven’t written many blogs talking about code for a while, but my notes are stacking up; so time to post some blogs discussing code! I’ll try to explain them the best I can for the non-programmers, or those that find C# hard to understand.
There was one bug fix where the developer took several attempts to fix it. Taking several attempts to fix a bug illustrates that you either – don’t have a good understanding of:
the requirements,
or the codebase that you are changing.
If you make a change and it introduces a bug, then you make another change and it introduces another – instead of playing “whack-a-mole”, it’s worth considering if you are actually writing the correct fix. From my experience, you can often just take a step back, ask for help, and come up with a much simpler, and less risky fix.
In one of their changes, I saw evidence that it was possible that they didn’t understand what they were changing, or taking care in their work.
case ParentRecordRelationship.Grouped:
//when a record is grouped, the associated text is NOT altered - so this method should not be called
throw new ArgumentException(string.Concat("Invalid parent record relationship supplied: ", parentRecordRelationship));
So we have a comment, explaining that the existing requirement is that the “associated text” is not modified, so it is completely invalid to call this particular method which would change the associated text (other code not shown). Therefore, we throw an exception which would cause the system to show an error to the user.
The developer changed the code to this:
case ParentRecordRelationship.Grouped:
newAssociatedTextValue = CreateAssociatedTextValue(string.Format(_groupedWithFormatText, parentrecordOriginalTerm));
break;
//when a record is grouped, the associated text is NOT altered - so this method should not be called
//throw new ArgumentException(string.Concat("Invalid parent record relationship supplied: ", parentRecordRelationship));
So now he has allowed the text to be updated in this situation. Unless that really is a change in requirements, then this is the wrong thing to do. Also, instead of deleting the code that throws an exception, he has just “commented” it out (which is why it now shows in green), and also left in the actual comment saying that this scenario is invalid; which now adds to the confusion when the next developer reads it.
To me, that shows that the developer is uncertain it is the right thing to do, otherwise you would remove the comment and the code. Just “commenting” the old implementation out basically acts as a reminder that you might want to restore it. (You could easily just look at the history of the file to see the old code anyway, it isn’t like it is lost if you actually delete it in the first place.)
He also added to the confusion with this change
//take the 1st 12 characters of the format text
itemValueStartsWith = _combinedWithFormatText.Substring(0, 12);
it is now
//take the 1st 12 characters of the format text
itemValueStartsWith = _combinedWithFormatText.Substring(0, 9);
This is a good example of why writing comments for simple code is bad. The comment explains a requirement that it should take 12 characters, but you can see that it takes 9.
To me, this shows a lack of care, and lack of attention to detail – which are basic traits that I think are important for good software developers.
I’m not sure how many people we offered jobs to during the recent recruitment drive, but 3 new Graduate Software Developers have started. We have never had a good induction process – we usually just expect people to start working on Day 1, but people won’t be familiar with our software, and the process.
Additionally, we always supply people with a stock laptop that could have been given to anyone in the business; so it doesn’t come with any development tools at all. So you need to install Visual Studio, SQL Server, and a few other things. However, these days, our IT has ramped up the security so now you cannot install anything without them remoting on to type in the administrator password, thus exacerbating the poor induction experience.
I wasn’t involved in creating the Induction process, the group of Senior Developers and Testers in India somehow went ahead without us in the UK.
They decided to use a Kanban board to track the tasks for the new recruits. They created tasks for each aspect like “Laptop configuration”, “Agile process overview”, “C# basics” and many others that made sense to me. The kanban idea was a good way of tracking their progress but it already seemed messy with 3 new starters but there’s more coming. I suggested that they use “Swimlanes” which can split the board into sections which can be used per person, but for some reason they rejected my idea in favour of their disorganised mess. So if there’s 10 tasks for each person, there’s 30 tasks that were initially on the backlog, and as they move to In Progress/Done, you cannot really tell how far each person is through the scheme without using additional filters, or configuring colours. Then when more new starters join, it becomes a complete mess with 10 more tasks being added.
I felt some of the tasks weren’t mandatory for the induction. One of them was Automation. Some developers in some teams are involved with automation, but it is usually given to the Software Testers. I think there’s different types of automation depending on the team you are in. The Seniors listed several types of automation, and provided links to LinkedIn Learning or Youtube – courses that were sometimes a few hours, but some were up to 8 hours. Then some were C# based, some were Java based, and some were Python based (it included JMeter, Selenium, Behave, PACT, Python, General automation). So you had to learn the base languages as a prerequisite.
“the videos are short, many around 7 hours, some are 1 hour”
Indian Senior Tester
When I saw that they had created a task that could potentially last 50 hours and wasn’t required for the job, I voiced my opposition to this idea and Becky, a Senior Tester agreed with me.
I said they aren’t going to learn if they are just watching videos, and won’t remember which is which. The constant switching of programming languages will probably hinder their retention. It’s very boring with the amount we are asking to do. This “Automation” learning task would already take a month to do if you are actually going to follow along and experiment with it. Then you have all the other induction tasks which involve reading, watching videos, and installing more software.
Becky pointed out we don’t even use this type of Automation in our particular teams so we shouldn’t ask them to do it. But then they said we “want to train them just in case it is used in the future“. We said we could just train them when it was needed, but they insisted it should be part of the Induction. Becky could sense they weren’t gonna back down so she asked that we inform them about which teams use automation and how often it is used so they can make their own judgement to learn it. They replied
“why should we inform them? we don’t want to set the expectation that they won’t ever use them”.
Indian Senior Tester
Towards the end of the meeting, he then said the new employees have already given feedback on the process. He said that all three agreed that:
“it’s hard to concentrate with all the videos we want them to watch, and all the reading we want them to do”.
Indian Senior Tester
Let me get this right. I said there was far too much for them to watch, and he argued with me about its importance, and then he said they have already complained about that exact problem, and they had only been here a week. Brilliant.
Stranger Coding Tings 