Mr Bates vs The Post Office
Discussion
Mojooo said:
I don't think the Inquiry is going to go into too much detail on what the technical faults are
I assume its either been agreed at the previous case or PO just accepts it clearly was fudged as so many innocent people were caught up in it.
Although as that Scottish guy said the other day, the problems only make up a very small percent of the millions of transactions so overall the system works (depending on you definition of what works means!)
As far as the SPM convictions and POL extrajudicial persecution/intimidation/extortion of SPMs not put on trial but ripped off and deprived of their livelihoods it doesn't work at all, those convictions based on horizon "evidence" are unsafe and it's likely the latter are too.I assume its either been agreed at the previous case or PO just accepts it clearly was fudged as so many innocent people were caught up in it.
Although as that Scottish guy said the other day, the problems only make up a very small percent of the millions of transactions so overall the system works (depending on you definition of what works means!)
Speed 3 said:
He's coming across as honest rather than slippery. The KC is trying to lead him into what the POL's motives were for system changes and quite rightly points out his role was to deliver the "what they want" not question the "why do they want that".
I don't buy that at all. Yes it is the job of a software architect/designer to try and understand what the customer wants but equally important is to understand why they want it. Why they want it is a function of how they intend to operate the system which in turn may influence critical design decisions. The old adage of the customer always being right is nonsense. Frequently the customer doesn't understand the system wide implications of something they've asked for or hasn't thought through the operational consequences and if you just blindly do it because you don't have sufficient subject matter expertise then there is a high probability the resultant system will be deficient, as this one is. Sometimes you have to protect the customer from themselves, other times you have to protect yourself from the customer. Fujitsu's reputation is in the mud because of this fiasco, if anything that happened was because they blindly implemented an ill-conceived PO requirement without push back or covering themselves with a paper trail of their advice it was a bad idea then more fool them.
Edited by siremoon on Wednesday 26th June 07:41
simon_harris said:
Every developer I have ever worked with has had 1000% confidence that the system they built was correct and working as intended.
We used to have an in house developed data processing solution that ran like dogs
t in a virtual environment and the dev team were adamant we were not allocating enough RAM, we proved conclusively they way they had written it mean that it used almost no RAM but did need a big frontside bus so as not to overwhelm the available CPU.
we built a dedicated physical machine to run it and ran it about 5000% better than compared their required/advised virtual spec.
Every developer I have ever worked with has had 1000% confidence that the system they built was compliant with the spec they were given.We used to have an in house developed data processing solution that ran like dogs
t in a virtual environment and the dev team were adamant we were not allocating enough RAM, we proved conclusively they way they had written it mean that it used almost no RAM but did need a big frontside bus so as not to overwhelm the available CPU.we built a dedicated physical machine to run it and ran it about 5000% better than compared their required/advised virtual spec.
I've rarely seen a spec that represents what the customer actually wants.
siremoon said:
I don't buy that at all. Yes it is the job of a software architect/designer to try and understand what the customer wants but equally important is to understand why they want it. Why they want it is a function of how they intend to operate the system which in turn may influence critical design decisions. The old adage of the customer always being right is nonsense. Frequently the customer doesn't understand the system wide implications of something they've asked for or hasn't thought through the operational consequences and if you just blindly do it because you don't have sufficient subject matter expertise then there is a high probability the resultant system will be deficient, as this one is. Sometimes you have to protect the customer from themselves, other times you have to protect yourself from the customer.
Fujitsu's reputation is in the mud because of this fiasco, if anything that happened was because they blindly implemented an ill-conceived PO requirement without push back or covering themselves with a paper trail of their advice it was a bad idea then more fool them.
That's absolutely the job of a good one, given the time and budget to do it. Looking back at the projects & implementations I've done, it has been very rare for those two to coincide Fujitsu's reputation is in the mud because of this fiasco, if anything that happened was because they blindly implemented an ill-conceived PO requirement without push back or covering themselves with a paper trail of their advice it was a bad idea then more fool them.
Edited by siremoon on Wednesday 26th June 07:41
Mojooo said:
Although as that Scottish guy said the other day, the problems only make up a very small percent of the millions of transactions so overall the system works (depending on you definition of what works means!)
That of course is essentially the same as saying of the thousands of sectors flown by Boeing 737 max aircraft (and some 767s which also have the same system), the flawed MCAS implementation only caused 2 crashes so overall the system works. Bonefish Blues said:
That's absolutely the job of a good one, given the time and budget to do it. Looking back at the projects & implementations I've done, it has been very rare for those two to coincide
It's a false economy not to do it. Trouble is too many programme managers think that timescales and budget are the only thing that matters. That's why so many software projects fail. Not enough attention is paid to the sanity of the requirements. For instance. I only worked as a senior software bod on one Government project. We built it and it worked. It was widely lauded afterwards in Government circles as a triumph and we even got a letter from the Cabinet Office saying how delighted everyone was with it. How did we do this? Simple, we told them at the outset that in our opinion all Government software projects fail because of bad requirements and lack of understanding of the operational environment so if they wanted it to succeed we had to make the requirements the focus of everything. After much debate, they eventually agreed. It was a bit late and a bit over budget but it worked and is still working 12 years on. Because it worked so well nobody ultimately cared it was a bit late and a bit over budget. They would have done if it was on time and didn't work. Lesson to be learned there.
siremoon said:
Bonefish Blues said:
That's absolutely the job of a good one, given the time and budget to do it. Looking back at the projects & implementations I've done, it has been very rare for those two to coincide
It's a false economy not to do it. Trouble is too many programme managers think that timescales and budget are the only thing that matters. That's why so many software projects fail. Not enough attention is paid to the sanity of the requirements. For instance. I only worked as a senior software bod on one Government project. We built it and it worked. It was widely lauded afterwards in Government circles as a triumph and we even got a letter from the Cabinet Office saying how delighted everyone was with it. How did we do this? Simple, we told them at the outset that in our opinion all Government software projects fail because of bad requirements and lack of understanding of the operational environment so if they wanted it to succeed we had to make the requirements the focus of everything. After much debate, they eventually agreed. It was a bit late and a bit over budget but it worked and is still working 12 years on. Because it worked so well nobody ultimately cared it was a bit late and a bit over budget. They would have done if it was on time and didn't work. Lesson to be learned there.
The problem is that clients asks can the system do "X" and of course the sales team automatically say yes. You then get into implementation and the technical guys from the software house clarify "yes it can sort of do that but not in the way you are now asking". That's when the cash register goes kerching and the blood pressure and disappointment rise.
The BR approach requires them to absolutely demonstrate functionality when you actually get in the room with them and gives the client project team a very clear view of what they should be asking. My BR sections of RFP's run to often hundreds more pages than the standard procurement sections. It also allows you to do a pretty robust desktop downselect by scoring their answers to the RFP before you spend quality time with the shortlisted ones. It's surprising how many software houses say it's the first time they've ever seen this approach.
As siremoon says, it's a complete false economy not to do this.
Speed 3 said:
I've made a good chunk of my living over the last couple of years with exactly this philosophy. I'm not an IT geek but I have fallen into this work as a result of being a procurement & process redesign specialist and the latter often results in an IT change. I consult with clients on technical projects (aviation mainly) and after an initial phase of process review & redesign I compel them to spend the most of their time writing their Business Requirements (to a template I set them) before we go anywhere near an RFP or supplier engagement. I've seen so many IT projects beset by scope creep (at best) and functional failure (at worst) because the client believed what the software salesman was telling them and bought a partially or wholly unsuitable product.
The problem is that clients asks can the system do "X" and of course the sales team automatically say yes. You then get into implementation and the technical guys from the software house clarify "yes it can sort of do that but not in the way you are now asking". That's when the cash register goes kerching and the blood pressure and disappointment rise.
The BR approach requires them to absolutely demonstrate functionality when you actually get in the room with them and gives the client project team a very clear view of what they should be asking. My BR sections of RFP's run to often hundreds more pages than the standard procurement sections. It also allows you to do a pretty robust desktop downselect by scoring their answers to the RFP before you spend quality time with the shortlisted ones. It's surprising how many software houses say it's the first time they've ever seen this approach.
As siremoon says, it's a complete false economy not to do this.
Great post, fully seconded. Many many software systems are designed around an idealised use case, and quickly fall off the reservation if your business doesn’t match. That of course used to be the key to successful ERP implementation - it only worked if you treated it as a BPR project with software as a bonus.The problem is that clients asks can the system do "X" and of course the sales team automatically say yes. You then get into implementation and the technical guys from the software house clarify "yes it can sort of do that but not in the way you are now asking". That's when the cash register goes kerching and the blood pressure and disappointment rise.
The BR approach requires them to absolutely demonstrate functionality when you actually get in the room with them and gives the client project team a very clear view of what they should be asking. My BR sections of RFP's run to often hundreds more pages than the standard procurement sections. It also allows you to do a pretty robust desktop downselect by scoring their answers to the RFP before you spend quality time with the shortlisted ones. It's surprising how many software houses say it's the first time they've ever seen this approach.
As siremoon says, it's a complete false economy not to do this.
One way I’ve found to keep software sales people on the straight and narrow is to never ask a question to which “yes” would be a valid answer. The same approach works for taxi drivers in many parts of the world, too - you don’t need a people-pleasing service seller
Jenkins in a bit of trouble this morning.
The inquiry have belatedly provided him with evidence that he was sent a document that set out the role of an expert witness, along with some agenda information for a meeting he was going to attend. Beer says that they only realised this yesterday.
Hence some of the statements Jenkins made yesterday are being revisited. I suppose he's on slightly stickier ground as a result, because he now can't say "nobody told me", it's more "yes, someone did send me this thing in passing once but I didn't take as much notice of it as I apparently should have done"
The inquiry have belatedly provided him with evidence that he was sent a document that set out the role of an expert witness, along with some agenda information for a meeting he was going to attend. Beer says that they only realised this yesterday.
Hence some of the statements Jenkins made yesterday are being revisited. I suppose he's on slightly stickier ground as a result, because he now can't say "nobody told me", it's more "yes, someone did send me this thing in passing once but I didn't take as much notice of it as I apparently should have done"
outnumbered said:
Jenkins in a bit of trouble this morning.
The inquiry have belatedly provided him with evidence that he was sent a document that set out the role of an expert witness, along with some agenda information for a meeting he was going to attend. Beer says that they only realised this yesterday.
Hence some of the statements Jenkins made yesterday are being revisited. I suppose he's on slightly stickier ground as a result, because he now can't say "nobody told me", it's more "yes, someone did send me this thing in passing once but I didn't take as much notice of it as I apparently should have done"
IIRC he should have signed off his "expert report" with an affidavit stating he had complied with all of the requirementsThe inquiry have belatedly provided him with evidence that he was sent a document that set out the role of an expert witness, along with some agenda information for a meeting he was going to attend. Beer says that they only realised this yesterday.
Hence some of the statements Jenkins made yesterday are being revisited. I suppose he's on slightly stickier ground as a result, because he now can't say "nobody told me", it's more "yes, someone did send me this thing in passing once but I didn't take as much notice of it as I apparently should have done"
I beat Mr Beer by 2 mins
LimmerickLad said:
Bonefish Blues said:
Uncomfortable man is uncomfortable
He's human and makes mistakes but not a bad person IMO..........unlike some of the other ar.eholes we've seen............still 2 1/2 more days to go yet though.His expert evidence convicted MANY innocent people, including a pregnant woman.
The fact that his has a genial, almost elderly, demeanour should not belie the fact that he was the expert witness who was a HUGE factor in this whole miscarriage of justice.
He *is* a bad person.
I also believe Paula Vennels and Angela van den Bogerd are equally evil.
All of them should see the inside of a prison....but I suspect the only one who might is your genial Gareth Jenkins.
mikeiow said:
LimmerickLad said:
Bonefish Blues said:
Uncomfortable man is uncomfortable
He's human and makes mistakes but not a bad person IMO..........unlike some of the other ar.eholes we've seen............still 2 1/2 more days to go yet though.His expert evidence convicted MANY innocent people, including a pregnant woman.
The fact that his has a genial, almost elderly, demeanour should not belie the fact that he was the expert witness who was a HUGE factor in this whole miscarriage of justice.
He *is* a bad person.
I also believe Paula Vennels and Angela van den Bogerd are equally evil.
All of them should see the inside of a prison....but I suspect the only one who might is your genial Gareth Jenkins.
Tye Green said:
smoking gun?
Gareth Jenkin's just admitted that he knew that Fujitsu could access Sub Postmasters accounts - he's on the ropes .........
I said a LONG time ago that I felt that Gareth Jenkin's could be the only one to see the inside of a prison cell. Gareth Jenkin's just admitted that he knew that Fujitsu could access Sub Postmasters accounts - he's on the ropes .........
Any top sysadmin (particularly one defined as a "Distinguished Engineer") will know where the bodies lie - they will know that there will always be a possibility of a back door, and it is very, very hard to imagine Jenkins not knowing this was done.
I'm a little behind (had to pause things), but Jenkins refuses to call it tampering, where we absolutely know that numbers WERE changed and people WERE prosecuted and jailed off the back of that tampering.
What a nasty piece of work he is: genial demeanour or not, he is a bad person.
Beer appears to be on him.
What a nasty piece of work he is: genial demeanour or not, he is a bad person.
Beer appears to be on him.
Gassing Station | TV, Film, Video Streaming & Radio | Top of Page | What's New | My Stuff