TSB Upgrade issues

[Rroff]

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

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.

 

[dowie]

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.

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.

 

[Diddums]

 

[D.P.]

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.

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.

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.

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

 

[413x]

snip

Doesn't really seem like enough to me.
I suspect heavy customer losses!

 

[Jokester]

Still not working here.

 

[ianh]

TSB APOLOGY LETTER

Just got mine too, only TEN whole days after the issue first started, gotta love corporate communications!

 

[Diddums]

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.

 

[doodah]

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.

 

[Diddums]

Just got mine too, only TEN whole days after the issue first started, gotta love corporate communications!

I'm just extremely glad that this didn't affect me. I'd have lost the plot.

 

[Burnsy2023]

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.

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.

 

[Rroff]

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.

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.

 

[dowie]

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.

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.

 

[Azza]

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.

 

[Maccy]

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.

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.

 

[D.P.]

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.

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.

 

[D.P.]

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.

Masking sensitive data is trivially done automatically. That isn't a manual process.

 

[Maccy]

Masking sensitive data is trivially done automatically. That isn't a manual process.

You would hope, but it is not in a lot of places I've seen sadly.

 

[D3K]

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

 

[dowie]

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.

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.