Making Yourself Redundant

I often find that managers end up writing jargon-fueled posts that don’t mean anything to me. It’s often just hype, or a slight change which makes no difference in the grand-scheme of things. So it just frustrates me or makes me laugh. I was talking to a friend about this topic and he said he loves it when they get the word “synergy” in there, so I was glad to read in in this post:

One thing is certain in life, and that is that change is inevitable. But change doesn’t mean it’s a bad thing; it means new beginnings, new opportunities, new ways to improve. Over the coming weeks we will see some change come to our Product Team. A new structure to bring synergy with our SAFe implementation so that we are better aligned than ever to deliver our hugely important product roadmaps over 2022.

Most notably, Product Owners will move to report directly into the appropriate value-oriented structure (Vertical Markets or Horizontal values).This change will reflect the need to provide autonomy to the relevant specialist areas enabling them to;

make clear decisions on their respective priorities.
bring the Product Owner and Programme Management teams closer together supporting their knowledge of the ‘Why’ and the customers that we are focusing upon.
provide greater consistency of resources working on specific areas based on the technology/product/market in which they specialise

Certainly sounds brilliant doesn’t it? The next bit made me laugh though.

As a result of these changes, the role of Head of Product Owners no longer fits into the product structure and so, unfortunately, George will be leaving the business. He’s been heavily involved in designing the new structure…

Wait…what? He came up with this new team structure and forgot to put himself in it?

Troy Hunt: The Responsibility of Disclosure

Troy Hunt is a cyber security expert and creator of the popular website Have I Been Pwned. I do read his blog and listen to his podcast in which he mainly discusses cyber security (obviously) but also discusses some life events and hobbies.

YouTube recommended me a presentation he did for AusCERT2017 about responsible disclosures. It’s actually an interesting topic how some companies are very welcoming for people to report security vulnerabilities, whereas others are very distrusting and can threaten to sue.

You can watch the presentation in full:

AusCERT2017 Day 1 Troy Hunt: The Responsibility of Disclosure

Otherwise, here is a summary of the presentation.

He begins by telling a story of how someone found a security vulnerability on a website, extracted loads of data, used some of the login credentials to get in. He filmed it all and put it on YouTube. He got arrested.

Even though someone like that could claim to not be malicious, he would clearly violate some laws like Computer Misuse Act.

So how can you investigate a security flaw?
How can you disclose it?
Where is the line between being responsible and irresponsible?

Troy has a “Sinéad O’Connor” test. Enter her name in the data entry field of the website. If the apostrophe in a name gives you an SQL error, then you know there is a vulnerability – it is prone to SQL injection. You don’t need to go any further and actually carry out the attack; illegally accessing data to prove it.

If you grab 1 record, the company is obligated to disclose this to the user who lost their data. If someone takes 10,000 records, it’s a bigger problem and more inconvenient to the company. Just 1 unauthorised access to a record sufficiently illustrates the point. Accessing more than you need is more likely to be met with a negative response and possible legal action.

He then goes through some more notable examples and attitudes to the disclosure:

PayAsUGym got breached and ignored the hacker. Although the hacker was trying to extort money, by ignoring them completely, PayAsUGym had no idea how bad the breach was. Initiating the dialogue could have at least given them more information to attempt to limit the damage.

Cloud Pets had a security flaw in their toy, but also had a publicly exposed MongoDB database which attackers wiped and ransomed. Later on, when journalists contacted the owner, he responded

“you don’t respond to some random person about a data breach“.
Spiral Toys CEO

As Troy says, random people are exactly the people that will tell you about a problem.

Australian Red Cross Blood Service disclosed their breach very quickly, put out communication through multiple channels, and apologised. Troy was impressed with this response. The problem was a third-party who placed backups on a public-facing server so they could have easily downplayed it or passed the blame.

For more info, Troy also has a blog about disclosures, including the example of Cloud Pets.

Jurassic Park: The Software Issues

I read Michael Crichton’s Jurassic Park recently.

It seems obvious to the average person that a dinosaur park containing vicious species such as the acid-spitting Dilophosaurus, the intelligent hunters Velociraptor, aggressive flying Pterodactyls, and the ferocious Tyrannosaur was going to end in disaster.

A more docile park could work as long as other mistakes aren’t made. If we ignore the dangerous dinosaurs, it’s essentially poor software and a malicious developer that is Jurassic Park’s downfall.

The software controlling the automation contains many bugs and is also closely tied to the security and surveillance system. Computer programmer Dennis Nedry is brought to Isla Nublar to fix some bugs and add improvements. However, he uses his access privileges to take down the system which allows him to physically access restricted areas and steal the dinosaur eggs.

So the software is bad architecturally from a security aspect, but then Nedry was a malicious insider that abused this software flaw. The power outage and the aggressive dinosaurs is the main catastrophe that happens, but there’s also the existing issue of dinosaurs leaving the island undetected.

They don’t realise the dinosaurs have been breeding because of the way the software is designed. The user has to enter a number for the expected number of dinosaurs, then the park is scanned and stops counting when it finds that amount; so the system can only report that same value or fewer. This efficiency was added because the scientists have only cloned female dinosaurs – so it is “impossible” for them to breed. However, the dinosaurs can change their sex due to a type of frog DNA also being used in the genetic cloning process. This means some dinosaurs have switched sex to male, and have been breeding. The increased population has gone undetected, and some dinosaurs have been hitching rides on the ferry off the island.

This is definitely a cautionary tale of software issues.

Configuration Manager tool – Text Matching

When we add new, optional features, we often put in a flag to enable or disable the feature for certain users. This allows us to slowly roll-out the feature, or only enable it for customers that pay the premium. If there’s problems, you can also disable the feature quickly without pushing out a new version of our software.

One team had decided to rename their module, and therefore were updating the configuration flag’s name.

A lead developer, who reviewed the change, questioned if they could do that without running into incompatibility issues. The project team’s lead stated:

“No, we have the feature validation at source and target separately before we do anything. So, there should not be any compatibility issues.”
Project Lead

However, I was convinced the lead developer was correct. We have multiple versions of our software deployed, but we only have one version of the Configuration Manager tool.

So let’s say in Version1, the new module is called “User Manager“, but in Version2 they want the module to now be called “Staff Management” – and so they update the main software and the Configuration Manager tool to use this new name.

When we use the Configuration Management tool for new users that are using Version1, we update their config to use the new name “Staff Management“, however Version1‘s software will be looking for “User Manager” and will not find it, so will think the module is disabled.

Existing users on Version1 with the old flag in their configuration will work as normal, but it won’t work for new users. For Version2 users, the Configuration will have to be redeployed since their config will have the old name, but Version2 will be looking for the new name.

If the Configuration Management tool used ID’s rather than matching on text; it wouldn’t be a problem, so we have screwed ourselves over there. Matching on text is rarely a good idea due to possible spelling mistakes, case sensitivity (is “User Manager” the same as “user manager“?), and usually less efficient matching on something else like a number ID.

I spent a while trying to think of ways around this issue. Ideas that I thought of involved writing complex database scripts, running scripts outside the release process and getting other people involved. But then I think all my ideas still wouldn’t solve the incompatibility issues and it seemed way too much work for something trivial.

The team were adamant they wanted to rename it though, but it didn’t really matter too much. Only our staff see the Configuration Management tool, and we can update the main software so the users see the new name. It just adds confusion if someone tells you to enable “Staff Management” but you can’t see the option, so they have to correct themselves and ask for “User Manager” instead.

I would have thought the project team would have ran through different scenarios to test if their idea was feasible for new and existing users. But even after questioning it was feasible, they were adamant there wouldn’t be any compatibility issues so I had to explain the scenarios to them.