TSB Upgrade issues

dowie said:
And I don't just mean some bad PR, and losing a few bonuses... some senior project managers, directors in IT etc.. having a few uncomfortable and rather shouty meetings without coffee with the CEO etc..
Click to expand...

They'll just get promoted into big roles in other large enterprises :( and then there will be surprise and consternation when the same kind of issues happen at those places down the road.
 
Rroff said:
They'll just get promoted into big roles in other large enterprises :( and then there will be surprise and consternation when the same kind of issues happen at those places down the road.
Click to expand...

Well you'd hope that this crisis tars their CV a bit... it isn't exactly a great achievement yet if they've been working on it for the past couple of years then they've got some explaining to do.

Unlike the people who get managed out and agree to "resign" rather than be sacked as it is better for everyone if they just leave quickly and are promised a good reference etc.. as part of the deal - they're the ones to worry about as they often fail upwards. Hopefully these senior TSB people get tarred by the thing.... on the other hand, people lower down the ladder who pull out all the stops and get this thing fixed ought to get out of there and get a new job + hopefully have a fair bit to talk about and will be respected a bit more depending on their role.
 
4L3Ofqd_d.jpg
 
sideways14a said:
I remember attending a talk on Agile a few years back, i had never heard of it before as i was just getting into PM at the time (toe dipping).
I was quite bemused at how they make this thing work, all i could think of is this would produce a massive disaster in a dev project.
Click to expand...


It does in many projects without a lot of care and a handful of luck. It works well for smaller projects that aren't critical. For larger projects it really pays to have proper planning, and extended testing and evlaution periods before anything goes close to the production environment.

dl8860 said:
You aren't wrong, but the fact remains that people in India will be paid much less than over here and therefore general quality standards are going to be lower across the board. It's not stereotyping, it's just how it is.
Click to expand...
The salary is lower due to living costs, not the quality of the engineering. The quality standards are often hgiher than you could get buying UK based engineering
 
Last edited by a moderator:
I only wish there was something I could milk them for. I'd go nuts, take every penny I can. Sadly their apology effort is largely useless.
 
Sounds like the CEO is getting torn a new one in front of MPs and he's still rather disconnected from what's actually happening to his customers.
 
D.P. said:
It does in many projects without a lot of care and a handful of luck. It works well for smaller projects that aren't critical. For larger projects it really pays to have proper planning, and extended testing and evlaution periods before anything goes close to the production environment.
Click to expand...

I couldn't disagree more. Testing is best done with proper representative loads using blue/green or canary deployments. Running with test data is just a false sense of security. The issue with waterfall planning is that if you're doing something even slightly complicated, you don't know enough to plan traditionally and it work out.
 
Burnsy2023 said:
I couldn't disagree more. Testing is best done with proper representative loads using blue/green or canary deployments. Running with test data is just a false sense of security. The issue with waterfall planning is that if you're doing something even slightly complicated, you don't know enough to plan traditionally and it work out.
Click to expand...

The companies I've worked for that have had the least issues with rolling out new systems have replicated some of the real data coming through in a closed version of the system for a few weeks before rollout - for instance one call centre had something like 20 rows for live agents and then a half row that was used for testing that would pickup on a percentage of the work coming through and dummy run it.
 
Burnsy2023 said:
I couldn't disagree more. Testing is best done with proper representative loads using blue/green or canary deployments. Running with test data is just a false sense of security. The issue with waterfall planning is that if you're doing something even slightly complicated, you don't know enough to plan traditionally and it work out.
Click to expand...

just use a copy of each days production data and your test data represents the same load...

Really just depends what you're testing but not hard to get realistic data, especially if you maintain a day -1 test region that basically just acts as production the day before.
 
Got the same apology email today as well.

As a few other people do I only use their current account as a savings because of the 3% so wasn't a massive inconvenience to me.
 
dowie said:
just use a copy of each days production data and your test data represents the same load...

Really just depends what you're testing but not hard to get realistic data, especially if you maintain a day -1 test region that basically just acts as production the day before.
Click to expand...
Depends if that data is commercially/customer sensitive though, might need masking which could be a timely process depending on how much data you need to test with.
 
Burnsy2023 said:
I couldn't disagree more. Testing is best done with proper representative loads using blue/green or canary deployments. Running with test data is just a false sense of security. The issue with waterfall planning is that if you're doing something even slightly complicated, you don't know enough to plan traditionally and it work out.
Click to expand...


As Roff highlighted, you don;t use test data but feed real data through in a pre-production environment at realistic load levels. Waterfall planning is tried, tested and works very well when properly implemented, and in many large projects it is the only system that can have a high chance of success and meet all the stakeholders requirements. Only in some environments does it make sense to use customers as beta testers and let them find the bugs, exposing them to huge security or safety critical issues. Rather than fixing bugs quickly, it is much better simply not to let the bugs get through to production in the first place. Otherwise planes fall out of the sky and power stations blow up.
 
Maccy said:
Depends if that data is commercially/customer sensitive though, might need masking which could be a timely process depending on how much data you need to test with.
Click to expand...
Masking sensitive data is trivially done automatically. That isn't a manual process.
 
also only use them for the 3% which was only supposed to last a year. 5% indefinitely is welcome, but still meager if the limit is on £2k savings
 
Maccy said:
Depends if that data is commercially/customer sensitive though, might need masking which could be a timely process depending on how much data you need to test with.
Click to expand...

I guess perhaps if done as a first time thing where someone needs to consider how to implement it. Generally wasn't needed where I worked (commercial rather than retail), but in some projects where the client was sensitive to it (Swiss banks are tighter re secrecy etc...) then it wasn't an issue as it is known about already and a solution has already been developed (issue applies to production data too which you obvs can't change so instead you can add some masking functionality to the application itself rather than need to change the data). But it isn't too hard to do either if you're dealing with a known potential issue and you know the fields you're going to have to mask/put random data in.
 
You must log in or register to reply here.
Back
Top Bottom