Tag: decisions

Project: Batch Approval

This long blog documents what I have been working on for the past year. I had made lots of notes with the aim of writing a blog, in addition to taking extra notes from chat logs.

We actually estimated the project would take around 5 months, but then an extra 2 months for testing and go through our slow rollout process. It actually took closer to a year. I’d say it was a combination of:

  1. realising the feature was more complicated than anticipated
  2. the UX team had little knowledge of the actual user experience
  3. managers changing or trying to change team members
  4. our slow release process
  5. 90/10 rule of project management

We were told the project was important, yet we were only assigned 2 developers (as in myself and one other). As the project came to a close, we were being integrated into our new team, therefore other developers could help out during the final stages.

Here is a list of all the people involved over the project’s lifetime:

Name (Core team in bold)Role
MeDeveloper (Team Lead)
DanielDeveloper
DeanDeveloper (Temporary)
DennisDeveloper (Temporary)
TinaTester
TimTester
ColinTechnical Manager
MaryTechnical Manager
OliviaProduct Owner
OwenProduct Owner
CarlCustomer Representative
AdamArchitect
AndyArchitect
GraceSafety & Legal Governance
UlrikaUX
UrsulaUX
I’ve made the names start with a letter to represent their job title, apart from Colin because he is a recurring person in my blogs. I’ll put reminders throughout the blog so it is easy to follow.

Current Software

To protect anonymity, I need to come up with a different theme for what the software is for. Let’s say customers request various restricted items of different severity. So a request could come in for a Hunting Rifle, and the user needs to know if they have the adequate licence to possess firearms and they are deemed medically safe in a recent time-frame. Possible warnings are shown which the user can dismiss/acknowledge e.g. “licence is up for renewal in the next 3 months”, “recent purchase of other firearms”. Standard users can create “Awaiting Approval” tasks and assign them to users with authority to approve. To approve them, the authorised users open the task list, view the details, then click approve. Many tasks have either no warnings, or low-severity warnings, so users often just glance at the info and click Approve. The system then sends the approved request to a central system, then loads up the next task. There’s a couple of seconds delay due to the “digital signing”, a couple of seconds for sending, then loading up the next record. To sign loads of tasks, it’s a very slow and laborious process. It’s a major source of complaints from our users.

Unsafe/Unofficial Automation

Carl [Customer Representative] sent a link to a video where someone was demoing a commercial automated tool that autocompletes the tasks. It waits for the system to load, clicks the approve button, then repeat. So you could set it running, then walk away from your desk.

I thought it seemed ridiculously irresponsible and would cause people to be sacked if they got caught using such a tool:

A) The program is now the one authorising the tasks, not the qualified user. What’s the point needing to have qualifications if you aren’t even going to read what is on-screen? If a task was wrongly approved, then the user would be accountable.

B) if you walk away from your desk, you are leaving your PC unlocked, along with your physical Security Key.

The creator had actually put a bit of thought into it though. If there are any Warnings that require another click to dismiss/override, then the automation is paused.

The video claimed that some users have up to 500 tasks to sign after a weekend. They charge a fixed yearly fee of £295, plus 7p per customer on the system per year.

“the robot does not get bored, does not make human errors, and crucially is a lot cheaper than the user’s hourly wage”

Promotional video for the Automation tool

Probably just makes robotic errors instead!

I said we should change the names of the buttons to try and screw them since it probably uses something like that to locate the button to click. It would be quite funny to make them dish out refunds.

The existence of the automation tool shows how much the users desire a better solution.

UX User Feedback

Given the existence of such an automated tool, it is no surprise that one frequently requested feature is Batch Approval. Our UX team put together some kind of interactive prototype and invited a few users to provide feedback on two designs. The alternative design was actually produced by Mary [Technical Manager] who has no UX qualifications. I’m not sure how that came about and why UX agreed to trial her design, but the feedback was actually extremely favourable to her design.

This caused her to be quite smug and maybe caused some animosity as we will see later. The ratings out of 5 were:

(Option A) 4.3 for Mary’s design

(Option B) 2.3 for UX Team’s design

For additional comments, one user commented:

“I prefer Option A by a country mile – Option B feels even worse than the existing system!”

Another commented:

“Option B feels more clunky, less user friendly than option A. A lot of clicking involved”

One even gave a threatening response:

“Option A or you’re gonna lose me and my franchise”

Shortly, there was a write-up from a conference where the feature was announced:

“This item is one that really did steal the show – this is something that our customers have been very eager to see us implement and are very excited to learn that we are busy developing this solution.”

“Busy developing this solution” made me laugh, because at the time, all I had was a dialog box with a couple of lines of text and a button.

Proposed Change

The general idea, is that the user is presented with key details from the tasks in a data grid.

  • They can click checkboxes to select which tasks they want to approve.
  • These are added in a queue to send in the background.
  • The user can continue working as they are sending.
  • The “digital signing” has to take place on the user’s computer so a large part is done client-side.
  • The user has to remain logged in until the process is finished.

This project had actually been discussed for years, but because there wasn’t much of a “commercial drive” for it – we would be giving users this feature for free – it was always low priority.

Product Owner: Owen

I think the initial planning was done by a different Product Owner but then when the project fully began, we were assigned a new Product Owner, Owen, who was new to the company, but he also gave me the impression that he was new to the role…but also didn’t seem very clever in general.

Here are some quotes that happened in various meetings (mainly Sprint Planning and Refinement).

Owen: "which work item is it?"
Me: “the one right at the top"
Owen: slowly scrolls...chooses 2nd item

Me: "it's not a Must, it is a Could"
Owen saves it with Must tag
Tim [Tester]: "No, Owen, you tagged it wrong, go back"
Owen: "Which WI is this?"

saves it with the Must tag again
Then goes back into the work item and gets confused
then goes back into it again. I think he needs rebooting

Me: "you need to set the state"
Owen clicks to close
Me: "you need to set the state, go back"
Owen is confused
Me: "left hand side Owen!"
Owen hovers over the right
Me: "left hand side Owen!"
Owen moves down

Me: "leave it as it is"
Owen "Which one shall I take out?"
I'm sure he is intentionally 30 seconds behind to wind us all up

Owen changes Story Points from 3 to a 5 without any discussion.
"shall we keep it at 5?"

For another item, I was talking about how the requirement is either obsolete, or needs a completely different approach from the initial proposal. 
Owen: "So how many points shall we add?"

"The system crashes when entering incorrect PIN and clicking 'OK' on error prompt"
Owen: "what was the behaviour before we fixed this?"
team: "It crashed"

We were discussing how we logged a bug a few months back but haven’t seen it occur since, so it will need some investigation to try work out what the recreation steps are.

“Assuming the bug still exists, how long will it take to fix it?”

Owen

Estimating software changes is hard, but I always think bugs are even harder to estimate. It’s only possible if there’s clear recreation steps, otherwise it is stupid to ask – we can’t fix it if we don’t know what the problem even is.

“depending on Grace’s [Safety & Legal Governance] feedback, do you know how long it would take to fix?”

Owen

Translation: can you predict what Grace would say, and given that she did say it, can you come up with an estimate for it?

I logged a bug about suggestions on how to improve a dialog. It would be up to Owen or UX to decide on the approach to fix it. Owen then asks questions along the lines of: “what do we need to do for this? do we need it?” I said it would be nice but it’s not my decision. Then he still asks “do we need it?” “can we close it?“

What’s the point asking me these questions, when I logged it with the aim of asking him to decide?

When the project deadline was looming, we ended up having multiple meetings to decide if there’s any features we could scrap, or defer to a later release. After the first meeting where we decided scope, he may as well have said “You know those items you said we need to do and couldn’t defer them, are you sure we can’t defer them”, because he was arranging subsequent meetings to go back over them. When we came up with estimates which showed that we would need at least another month, he was then arranging another meeting to re-estimate them.

The Architects

An important project started around the same time ours did. Our architect, Adam [Architect], was reassigned to the new project. Andy [Architect] joined our team as a replacement. He wasn’t completely new to the company but wasn’t familiar with this area of the system. Additionally, I don’t think he even looked at the software or even requested a demo.

Any question we asked him, he ended up making an excuse that he was busy and will get back to me later. Then when he did answer, I then sent a message to the original architect, Adam, and he said Andy had asked Adam about it and simply relayed the message back to us. So basically Andy wasn’t doing anything. We had him officially assigned, but it was Adam [Architect] that was answering the questions but via a middle-man.

The July Cancellation

There was a bit of disruption when our project looked to be cancelled, but there was apparently some mis-communication.

Hi All, a decision has been made by Directors to stop Batch Approval and to move resources across to pick up Project France instead. Therefore I will be cancelling the Batch Approval meetings.

Project Manager

1 day Later

The directors had decided to move you to the new project so I cancelled the meetings, but then I find that there wasn’t a firm decision from the Directors.

Project Manager

Brian has asked us to proceed with Batch Approval as originally planned. Sorry about the chaos dudes. They must be smoking some good drugs upstairs.

Olivia [Product Owner]

It was off the table, then someone put it back on the table, then someone else swept it off the table, then someone picked it up off the floor and put it back on the table.

Andy [Architect]

Coding Tales

Colin [Technical Manager]: "What sprint are you in?"
Me: "I dunno"
Colin [Technical Manager]: "you are the team lead, you should know"
Me: "No one in the team knows"

Put it in a new tab but make it behave like a dialog

The original UX designs looked like it fit nicely in the existing Task Framework. The requirements were that Batch Approval had:

  1. Its own folder but is a sub-folder of Approvals
  2. Opening a task opens it in a new tab

After looking at the code though, the framework didn’t actually support a sub-item. But we found a basic workaround to make it look like it did. However, there were quite a few features that we got “for free”, but we didn’t want them because they weren’t appropriate for a sub folder. So I had to disable the features by hacky code.

If you double click a task, then it opens in a new tab, which is what they wanted. However, they then didn’t want you to be able to navigate away into other parts of the system, and the Task Framework didn’t support that. With a bit of a workaround, I got that working, but the tab was designed to view one task only, and we are displaying a Batch of them. A few weeks went by and I managed to cobble something together, but the code was awful.

I took a step back and thought about it.

  1. We have a tab that the users surely would expect to be able to move away from to view other tabs.
  2. I’m using this “tab” which is designed for a single task, and I want multiple. So I had to make my own custom page.
  3. We have hacked a sub folder and had to basically fight against the codebase to get it all working…

So why don’t we just have a button on the main folder, and it launches a modal dialog?

  1. It would take a couple of days to get working,
  2. the code would be neat,
  3. and I think it’s what the user would expect.

After speaking to UX about it, they were happy with my proposal. I had wasted about 3 weeks trying to get it working like they previously wanted. Also, we are again telling UX what a good UX design is.

Scrollbar

The UX was also clear that we didn’t want a scrollbar to appear, and instead we use pagination. I didn’t see anything obvious in the standard DataGridView Winforms control, although I’m sure this is a common problem/requirement.

I ended up writing my own logic to add controls to the grid, keep track of the size, then stop adding when the size exceeds the height of the control. However, if there is only 1 very large task, we have no choice but to use a scrollbar.

The problem we encountered was that sometimes a scrollbar did appear when it shouldn’t. I made some tweaks to the calculation and it seemed to work fine. But then a Tester found a combination of task sizes where it still appeared. I couldn’t work out what I was missing in the calculations but it seemed about 4 pixels off, so I just added that into the calculation. Again, all seemed fine for a few days, but then the Tester found a combination of sizes where it still appeared.

Olivia [Product Owner] suggested that we detect when there is a scrollbar then disable the Approve button until the user scrolls down.

I said if we know when the scrollbar is there, why don’t we just remove the last task and check for the scrollbar again, repeat until the scrollbar has gone. I thought the code would be messy, and I’d end up writing a stupid code comment like “mate, something has gone wrong with the calculations here, so we’re gonna have to do some jiggery pokery to get out of this mess”.

Adam [Architect] did suggest some alternatives and they were just as wildly wrong.

Dean, a developer in another team agreed to help, and after a couple of days, he says “you can just set the vertical scrollbar to be disabled”.

But if the scrollbar is appearing so you have to scroll to view the content, then surely disabling the scrollbar will mean content is off the screen?

I tested his idea, and it worked fine! What must be happening is that the vertical scrollbar appears and takes some of the horizontal space… which causes the text to wrap and creates the need for more vertical space. Therefore the scrollbar is required and so remains. But if you tell the scrollbar it cannot appear, then the controls are added, and my calculations meant it fit perfectly in the grid.

It’s a self-fulfilling prophecy!

Olivia [Product Owner]: Do we have concerns about the unknowns?
Tim [Tester]: It's just the unknowns that we don't know about
I feel like you need to know the system inside and out to be able to safely implement this

Conflict With The UX Team

UX: “We want to minimise pop-ups”
Also UX: “Add a pop up after closing the dialog”

Ulrika [UX] had to take time off to deal with some personal problems. Ursula [UX] agreed to join the meeting we arranged on the Wednesday.

“I don’t work Thursday/Friday and have to leave early on a Wednesday to get the kids. I’ll get back to you next week”.

Ursula covers for Ulrika but then also has time off.

When she got back to us, she seemed to overlook how users access this restricted part of the system, and it turned out none of the UX team actually had this knowledge. So halfway through the project, we were discovering new requirements because they hadn’t designed the user flow.

Don’t Have Time

In early January, we were waiting for UX to give us some approved text but they seemed to be taking their time. I asked Olivia [Product Owner] what was going on, and she said that we don’t have time to make any more changes so they “needed to stop requesting changes”. Even though I pointed out that I was the one requesting changes, she said “we don’t have time to test” (even though it only involved quickly checking some text has changed on a message box). Nearly 2 months went by before we actually began to release.

After more protests from me, she says:

“The text is fine for now. We don’t have time to be changing it.”

Olivia [Product Owner]

When it came for the final review, reviewers questioned why we had dialogs with some ToDO comments on it saying “ToDo: Awaiting UX approval“. Even if you don’t have comments like that, I have seen developers question the user-facing messages if the grammar isn’t correct or sounds unclear. It definitely wasn’t clear because we just wrote the first thing that popped into our heads at the time; knowing the text would be replaced.

I think what had happened was that Mary [Technical Manager] and Olivia [Product Owner] had fallen out with Ulrika [UX], and then was refusing to authorise her changes. Remember, tensions will have been building since users criticised Ulrika’s design and wanted Mary’s design, and Mary’s arrogance about it wouldn’t have gone down well.

It’s just part of the process though – all text needs to be approved by the UX team; otherwise what is the point of their team?

Conflict With The Architect

When we implemented Adam [Architect]’s suggested invalidation logic, we thought the criteria was too restrictive. Adam was off on annual leave for a few weeks so we couldn’t consult him. So we made our own decision to change it, and got Carl [Customer Representative] and Grace [Safety & Legal Governance] in agreement. However, when the Architect saw it, he said it was unsafe. In many meetings, I got the impression Grace wasn’t really listening and she tended to agree with what we said. Not exactly great when your job involves telling the team what is safe and legal, and then get overruled by the Architect.

We came up with a compromise, and implemented it. Then when it came to the Code Review, Adam suggested removing one more of the sub-rules which I think would be perfect, but then Olivia [Product Owner] was reluctant for us to make more changes.

Then a week later, Olivia said she would arrange another meeting to discuss the rules because she felt it might be too restrictive. OMG. However, she then seemed to have personal grievances with Adam, so told me not to make the simple change, even though it would be what we want. She used the excuse of lack of Testing time. 

Adam [Architect]  
We shouldn’t be knowingly introducing bugs. 

Olivia [Product Owner]
This is not a bug. It’s a change to the criteria and we are not going to change it a week before we finish. I am speaking to Carl [Customer Representative] about changing the criteria, and we’ll look at it then.

Adam [Architect]
A bug is any deviation from requirements. Why are you planning on changing it if it is not a bug?

Olivia [Product Owner]
That’s not a bug. You are right in the sense that we need to change it…we’re just not changing it now. I was happy to leave it as it was to get this out of the door. That’s my call to make.

Mary [Technical Manager]
There's a lot that's not right. But how long do we keep going until we give it to the customers?

A summary of how this situation appears to me:

  1. There is a process, but if you declare you want to move the process to the next release, then it is fine.
  2. It will take too long to change a few lines of code, so we ain’t doing it. Apart from when it is a comment on the Code Review, then we are doing it, apart from those that we aren’t.
  3. It takes longer for Olivia [Product Owner] to argue against it than to fix it.

The CEO had recently posted:

“The most important thing we do every day is keep our users and their customers safe by managing risk effectively. I know you all know this, but it warrants repeating: safety is our number 1 priority all day, every day – regardless of anything else that is going on. It trumps everything. Please always remember that.”

CEO

Our Managers are like:

“Next release”

The Technical Manager change

Colin [Technical Manager] complains that Daniel [Developer] and I haven’t handled the project well – and it overran by over a month at that point. A week or so later, the team was on a call with other stakeholders and he said

“you guys have done a tremendous job”,

Colin

then said the delay “was caused purely by scope-creep and nothing to do with the developers at all”.

“Mary is in charge of the team since yesterday”

Colin [Technical Manager] with his timely announcement

I got the impression that Mary just wanted to get rid of the project, because it was dragging on for far too long.

The Testers had nothing to do since us Developers were working on the last few bug fixes. Tina [Tester] said she was just re-testing old features to pass the time, but also get extra confidence there are no remaining bugs. Mary [Technical Manager] replied:

“should we be doing testing when changes are ongoing?”

Mary

Well, in that case, this statement means testers should only be hired for a couple of weeks right at the end of a project – since changes are constantly ongoing. I think she might have intended it to mean like “you’d better not find more bugs!”, but if there are bugs, then you definitely want to find them before our users do.

On the last day of the Sprint, Tina [Tester] took annual leave. She had left her assigned items in the “To Test” column of the Kanban board. There was no evidence she had tested the item, so I don’t think it wasn’t a case of just forgetting to move to “PO Approval” column. Olivia [Product Owner] and Mary [Technical Manager] then decided to just close the items. No evidence, no demo – just close them so the Sprint looks good, and looks ready to release.

What annoys me is that Mary had criticised how we had run our team and suggested we don’t follow the process. She stated that she perfectly follows the process – which leads to her successful projects. Then I see her cutting corners like that.

Just like Colin, she criticises me to my face, but then when we are in a group she states:

“I think you’ve done a fantastic job given that there’s only 4 of you”

Mary

A few days later, I had finished what I was assigned, but there was a bug on the backlog which Mary [Technical Manager] seemed to want to defer (again, she just wanted to release the project as soon as possible). I thought it couldn’t be released without this fix. I stated that I would like to look at it and she said:

“don’t do any development work”

Mary

Seems I have the day off then. What is the point in me sat around doing nothing? If I fix it, we can decide if it goes straight in, or deferred for the next release. Or maybe I won’t even find a solution. She just seemed desperate to finish the project so wasn’t considering the seriousness of the bug, or thinking logically at all.

The Backstab

I didn’t actually sit around doing nothing. I worked hard and found a solution. I knew that there was no chance Mary would accept my changes, so I needed to come up with a way of convincing her. My plan was to get the testers to informally test it, then I can say that I have a fix, and the testers are happy that there’s low risk of introducing more issues – so she would be stupid to reject it.

Testers Tim and Tina were in agreement that the fix should definitely go out in the initial release, and they agreed Mary was making a bad decision to consider releasing without it.

Tim said he would “have to check with Mary if he was allowed to spend time testing it” since they got told not to test anything. I said “there is no way she would approve it, that’s why we are doing this informally/secretively”. If Tim and Tina test it and find a bug, my plan has failed and Mary never needs to know that I attempted it.

It’s a perfect plan, or it would have been, but Tim then goes and tells Mary that I asked them to test it.

“You gotta start being better with your comminications – it’s not just yours and Tim/Tina’s decision if something gets put into the release – it’s a whole team decision but ultimately mine and Olivia’s. You’ve messaged them directly asking if they can get it tested, and as much as they’ll also want to get it done, it then puts them under pressure. This is how you’ve all got to a stage of being all over the place and burning yourselves out, it’s got to stop please.”

Mary’s chastisement

I shouldn’t have to go behind people’s backs and make my own decisions, but the entire non-management side of the team thought it should go in, and only the managers thought it shouldn’t. As a team we care about quality, but managers are just focussed on deadlines.

I also didn’t appreciate that she is accusing my decision making of adding stress to my team.

80% coverage

As the project got towards completion, I recalled our stupid “Merge Ready” process that no one seems to care about other than the small team who came up with it. You have to justify the likes of Code Coverage, and ours was at a low figure like 10%.

I’ll write some blog posts about my reasoning on when tests are good or bad in the future. A simple explanation is that Units tests are good when covering requirements, but often developers write them to cover implementation i.e. verify a particular method is called; but not that the particular method actually works. When you switch implementation, you have to rewrite a new unit test, slowing you down. Unit Tests are supposed to help you refactor, but in this case, it is a hindrance to refactoring. We did a lot of prototyping early on, and knew there would be large re-writes, so Daniel [Developer] and I decided to worry about Unit Tests later on.

When I declared the low number of Unit Tests, Olivia ended up raising it to the Directors for some reason. Why was it their concern? Do they even know what Unit Tests are for, and what the coverage actually means?

It could jeopordise my chance of payrises (I was correct, I got 0% this year) and tarnishes my reputation.

When Mary joined the team, she berated me over this decision and made the dramatic statement:

“We can’t go on like this”

Mary

She then asked a couple of her favourite developers to write some Unit Tests for my project, completely undermining me.

The thing is, both Dean [Developer (Temporary)] and Dennis [Developer (Temporary)] spent way longer than they estimated, and they didn’t do as much as they hyped, then when it came to make the last few changes, it slowed us down.

We ended up around 22% in the end, and the managers decided that is fine.

That’s the problem with us though… Do 80% coverage because it’s important. But actually it’s not that important, so you don’t need 80%. But TRY get 80%, Why?, Dunno, but the Document says.

Tim [Tester]

On track

Dennis [Developer (Temporary)] was also asked to helping out address the Code Review comments. In some ways, this kinda slowed us down. I told him I had a branch with some changes in already and sent him a link to it so we can work together. When I caught up with him the next day, he said that he had been working on a few of the ones I already had done because he hadn’t looked at the link. What a waste of time.

When Mary asked for a progress report, Dennis reckoned it would take 1 day to go through 20 comments, but he had done 8 easy ones the day before, and we had the hard ones left. So I said it would be more like 4 days, but could take longer if they are surprisingly complicated. I was correct.

Final demo

On the final Project Demo, Carl [Customer Representative] was saying the sending process was far too slow. He had been on most of the demos from the start and saw the progress across the project.

The original version I showed him was incredibly slow, but I had managed to speed it up significantly. So despite him witnessing the project months ago, he said the performance was a concern and maybe users would think it wasn’t a significant improvement.

We had all kinds of people turn up to this final demo. People from support, training etc. We should have had those guys on the early meetings. They were prodding holes in the requirements and asking important questions. Although we gave good answers for most of them, I couldn’t help but think our changes might not be as useful as we thought.

If only we got more users involved throughout the project, rather than just some UX mock-ups before we started, and then a year later – give them the update and hope for the best.

I’d like to reiterate just how hard the team has worked. They have worked their little socks off

Olivia [Product Owner]

Conclusion

We were told the importance of the project, but because there wasn’t a direct commercial aspect to the project, I felt it wasn’t backed up by the number of developers assigned to the project. With only 2 developers, then key staff like Architects and Product Owners switching throughout the project; it just slowed us all down and made us all feel it was actually a low-priority project.

There were other morale-reducing aspects like when we were told the project was on hold, then Mary berating my decisions, and implying the failures were down to me.

There wasn’t a great understanding of the feature in many ways, illustrated by

  1. how many requirements we discovered throughout the project,
  2. the UX team being clueless about many aspects,
  3. one Product Owner so clueless – it seemed he struggled to use a computer,
  4. then switching to a clueless Architect that just went straight to the original architect.

Recruiting Graduates #6: The Disappointment

Last year, I wrote some blogs explaining how the hiring process for Software Developers is bad.

General Summary Of Why The Software Developer Hiring Process Is Bad

When I was involved in trying to come up with something better, I was frustrated because I didn’t have the answers, but I felt everyone else involved didn’t understand my concerns.

I hate the way Tech Interviews and tests currently are, but I think it’s hard to come up with something as a replacement. When researching example questions, I see lots of questions along the lines of “who invented Object Oriented Programming?“, and I think “I don’t care“.

Then there’s loads of aspects that you would just Google if you didn’t know it e.g. memory usage of each type.

Or you may get questions like “what is wrong with this code?“, but if you actually pasted that code in Visual Studio and try and build it, you would see the error. Or in the case it is valid but not advisable; Code Analysis would flag it. Some of these can be trick questions like mathematical logic where the order of execution is ambiguous, but Code Analysis would definitely flag to tell you to add brackets, so it’s silly having these as a question.

Then I hate all the generic Fizzbuzz stuff (check if a number is divisible by 3 or 5, or even both). These are just so cliché that people could just learn from memory anyway.

Also, what do these graduates we are targeting actually know? back in my day, I knew Java but I was terrible and didn’t know how to test properly, or even debug. So there’s no point testing them on that either.

Stupid Questions From The Internet

During our meetings, I asked the team how they were coming up with the interview questions, and they said they were just Googling for C# Interview questions. This is problematic because applicants may have read and learnt from these very sites, but also many sites had terrible questions, which were sometimes incorrect.  

I came across this website:
https://www.includehelp.com/mcq/is-the-use-of-return-statement-necessary-in-every-function-in-csharp.aspx

 95. Is the use of return statement necessary in every function in C#?

 Yes No

 Answer: A) Yes

 Explanation: Yes, the use of return statement is necessary in every function in C#.

I think some programming languages may differentiate between “methods” and “functions” where “functions” always return something. But in C# you just call them “methods” which can either return something, or be defined as “void”. So this is just incorrect.

 99. Which is the first line of a C# program?

 using System;

 using system;

 using Namespace;

 namespace MyApplication

  

 Answer: A) using System;

If you create a blank class, “using System;” is the first line, but A) you could remove it B) the order of using statements matter C) in modern C# you could move it to a “global namespace”. I also asked the question of “who are we targeting?” because everyone was coming up with C# specific questions. My colleagues told me the universities we were targeting were primarily coding using Python! So we were writing the wrong test, or targetting the wrong people.

The Performance Review

In my recent performance review, my manager Colin stated:

“You were given an opportunity to lead on defining our interview process, but have not shown much interest in it. Ultimately someone else led it, creating the interview pack, redefining interview questions and leading live interviews, which I think is a missed opportunity to shine.”

Colin

I argued that: although I didn’t have a huge impact on the end result, it would have been a bigger mess had I not pushed back on some of the questions. Although it seems some of the interviewers still asked questions I said weren’t suitable.

We ended up coming up with a terrible process that some candidates dropped out of, and the ones that went through with the interview struggled and we were left with the decision to gamble based on what little we saw.

The Best Hire

One of the best hires we made was someone I didn’t interview, but I looked at the interviewer’s notes, and he didn’t exactly look like a strong hire. 

  • Implemented the basic application to consume webapi and just printed the values based on some predefined values
  • No unit testcases were written
  • application is simple
  • Inheritance – simple explanation
  • polymorphism – no idea
  • interface – not good explanation
  • purpose of inheritance – No idea
  • Print the numbers and its occurrences – Not completed, but after showing the hints he completed
  • Print the number from 1 to 100 using Recursion – Completed
  • print the numbers based on divisible values – Completed
  • Logical, cut the cakes into 8 pieces with 3 cuts – Completed
  • Candidate lacks on syntactically at some areas, but has some logical solving skills and good attitude on approaching things

When I stated to Colin that it “wasn’t a great batch of hiring”, Colin said out of the people we did interview, we ended up hiring around a third of them – which he said was above the normal hiring rate. I said that it was only above the hiring rate because we hired people that should have failed. Then later, he quoted the numbers “15 interviewed. 4 hired” (more like a quarter then). But there were loads of applicants rejected before the interview stage, and others dropped out along the way.

Intermission: Bantz from Twitter

The Polymorphism question

The Polymorphism question that was asked on some of the interviews was basically “do you know the types of polymorphism?”   

I didn’t even understand the question, and I probably have 10 years of experience.

I was only thinking about the usual polymorphism where you can refer to derived types as the base type:

 IAnimal animal = new Dog();
 animal= new Cat();

To check if I wasn’t going mad, I asked some of my colleagues. Here is how they responded:

“not sure i do, no. Inheritance and Composition, are they right?”

Dean (Senior Developer around 10 years experience)

Like covariance and contravariance? But I don’t think I could put it into words. I guess you have real polymorphism and fake…virtual functions have a virtual function table that map overridden functions from base classes. But a lot of polymorphism is just the compiler being intuitive and going “you’re not crazy” it can be treated as that type. 

Adam (Software Architect)

Types? an interface can be implemented many times. A method can have the same sig but different parameter types etc

Rob (Senior Developer around 20 years experience)

According to https://www.bmc.com/blogs/polymorphism-programming/, there’s Runtime, Compile Time, Overloading, and Casting. So if very experienced developers can’t explain the concept, then why are we using the question to target Graduate developers?

Conclusion

It annoyed me that Colin stated “have not shown much interest in it”. I was trying to make sure we had well-defined objectives on the exact type of developer we were hiring. Everyone else just started copying questions for the internet without considering the knowledge and experience of the people we were targeting. I didn’t have the solution of how to make a good software development hiring process, but I really wanted to make sure we got close – but I just didn’t have any support from everyone else that was involved.

Burndown Chart: tasks

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.

:all-the-things:

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. ¯\_( ͡° ͜ʖ ͡°)_/¯

How Software Bugs are Prioritised

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.

Women In Tech: Software Developer Transition To Manager

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.

See Also: Women In Tech / Programming Podcasts

Bug Bash

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.

Software Support Call Centre

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"

YAGNI / This Code Could be Useful In The Future

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!

https://swizec.com/blog/dry-is-a-footgun-remember-to-yagni/

A simple example I came across recently was this:

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).

Elon and Twitter

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.

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

Corey House recently tweeted about “Chesterton’s Fence”, and I was keeping my eye out for an excuse to put it in a blog. So here goes.

“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

Top 5 Software Redesign Mistakes By Software Companies

I was watching Jayme Edwards’ (aka Healthy Software Developer) “Top 5 Software Redesign MISTAKES By Software Companies!” video, and thought he made some really great points.

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).