TSB Upgrade issues

I remember the days when programmers had real brains, they would sit huddled over a C64,Amiga,Atari ST and write code that performed magic with the tech they had.
Nowadays, well... any tom dick or harry can call themselves a programmer or developer and ***** out a barley working piece of tat that needs several dozen revisions before it even start doing what it was promised.
Blame several things, poor teaching (i have seen many of the course work we give to our students and its laughably crap) / marketing and sales... (yes sure we will have that done for the customer, moon on a stick it was wasnt it?) and the internet... cos now you can spam the world with crap and update it easy as pie... in the old days you needed to release floppies and what not , now... bah go on the web and get the latest patched version.

Crap.
As for TSB, i wonder where there main IT support and developer base is... hmm could it be in another country ... one that begins with an I for example.???
 
Seems to be the way these days:

(A) modern project management - too many people disconnected from the whole, too many people making executive decisions who don't understand software development, often a rigid schedule that means once one part has been committed there is a lack of flexibility to perfect it or sort little issues, etc. unless a major show stopping bug is found combined with only listening to user feedback that fits what the developer wants to hear.

(B) Too many career programmers with limited ability to step off the established path they've been taught and little pride in their work or willingness to really make code robust, etc. as long as it mostly sort of works as intended that is as much as many seem to care these days.

There is an element of making sure things keep moving along i.e. it is very easy to get so bogged down in over-perfecting one part of a project it seriously delays or stalls the whole thing but still.

EDIT: Reminds me of a job a few years back - I got so fed up with the archaic, with a lot of manual re-entry way we were moving data between two systems that was costing vast amounts of money due to the time, inefficiency and inaccuracies involved that I coded a proof of concept in an afternoon which was like 90% actual functional - but obviously you can't put something like that into a live production environment without proper qualification, testing and documentation, etc. more than 6 months and a 6 figure sum (some was on updating hardware mind) later the external IT provider produced a system that was less functional and far more buggy than what I'd thrown together in a few hours :(
 
Last edited:
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.
 
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...

dunno, plenty of **** software projects out there using more traditional methodologies too
 
dowie said:
whats with the Netflix exception???

edit - apparently a library called ribbon released by Netflix
Click to expand...

https://github.com/Netflix/ribbon

Edit: Too slow. I wouldn't be too reassured if these errors weren't being caught by a banking app though, smacks of a bunch of offshore devs just slapping code into a project and shipping it.

Could be worse I guess, Ajit Hatti did a good amount of work on the pitiful security some banks operate, including doing verification on the client side.
 
Last edited:
Still struggling to log on, this has been a complete disaster.

I have a few bills I need to manually set the payment up, hope it gets sorted this AM.
 
Rroff said:
Seems to be the way these days:

(A) modern project management - too many people disconnected from the whole, too many people making executive decisions who don't understand software development.
Click to expand...

It didn't create too many issues but I thought it was strange that the project manager of the app developer we used in work had no software knowledge at all. You would have to describe the problem to her then she went to the programmers. I don't understand why we couldn't deal with them directly. Ended up going that way in the end though.
 
Still got no access and being abroad I can't pop into a branch, yay! I would try phone banking but so far I'd spent over 45mins on hold just trying to get through without success, double yay!!!
 
I've worked for many large banks in various roles in IT from 1987 until now (including Lloyds TSB for a long time). I even worked on mainframe development back in the day. The differences between then and now are stark:

* We all had a passion for IT back then. Nowadays some people do but others are simply in the job because of the relatively good pay and conditions rather than a love of programming.
* Most people back then were programmers. Nowadays most people are managers or people pushing spreadsheets around to show whether the small number of programmers are on target.
* Back then we all sat in the same building and often on the same floor. This included application teams and infrastructure teams. If you needed to know something you went and tapped someone on a shoulder. If you needed a meeting you would all jump in a room. Nowadays I work with people in diverse countries. I only ever get to talk to them on email or over a very poor quality phone line, often with people who can't speak very much English so you can never truly know if you understand each others question/answer.
* Back then we could slip a project date if necessary. Nowadays dates can't be slipped and something has to be de-scoped to meet the deadline and protect the upper management bonus. It then fails on day 1 in production.
* Back then if I needed another team to do something I would ask the guy I knew in the area. Nowadays I have to fill in a form which goes into a queue of work to be done by someone who doesn't understand the system I'm working on and expects me to list out exactly what they need to do without me even knowing what they need to know.
* Back then we valued customer experience. Nowadays everything is so driven by cost that decisions are sometimes taken that risks customer impact to save a few £. It's cheaper to fix the problem later than get it right before it impacted the customer.
* Back then we had a small number of well paid, highly skilled people with strong business domain knowledge. Nowadays we have more people, mostly low paid in other countries, with little domain knowledge and certainly a big loss of direct knowledge of the systems they are working on.


Working in a large company nowadays is soul destroying and I can completely see why large projects fail, or at least don't work initially.
 
In my experience too much mid-management trying to justify their own inflated salaries, and possible some poor quality outsourced IT
 
MikeTheNative said:
It didn't create too many issues but I thought it was strange that the project manager of the app developer we used in work had no software knowledge at all. You would have to describe the problem to her then she went to the programmers. I don't understand why we couldn't deal with them directly. Ended up going that way in the end though.
Click to expand...

:D

 
Delvis said:
Makes you laugh really because historically some brilliant minds have come out of that part of the world.
Click to expand...
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.
 
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...
I see the issue is one of both high and low pay at the same time. On a spreadsheet it appears cheaper to pay several developers in India than it is to pay one or two developers in the UK. So there is a strong argument to offshore work. In India itself IT is a fairly high paid job compared to others. So there is a strong motivation for people to want to do the job. Some will be excellent, very involved in the work and love programming just like here. But others will not be interested in the job and just want to do it for the money.

I believe we're less likely to recruit huge numbers of poor quality UK based programmers simply because they are more likely to be employed directly by the company concerned. So they have control over the hiring and firing processes. But with offshore staff it is quite common for a large company to outsource the work to the consultancy who then recruit large numbers of people. I've seen examples where poor quality people simply get moved between accounts rather than fired.

Cheap offshore labour means UK companies just want to get cheap people working indirectly for them.
High local pay in India will attract both highly skilled and poorly skilled people to fill those positions.
UK companies lose direct control over the quality of people they hire.
 
You must log in or register to reply here.
Back
Top Bottom