Oh you mean someone having to manually change it? I don't think that is applicable here, you're talking about a huge amount of data - it has to be an automated process.
TSB Upgrade issues
- Thread starter android-fan
- Start date
Oh you mean someone having to manually change it? I don't think that is applicable here, you're talking about a huge amount of data - it has to be an automated process.
Yeh manually using a spreadsheet/macro/whatever, but also people not knowing how to use the automated tools properly either!
Man of Honour
- Joined
- 17 Nov 2003
- Posts
- 36,746
- Location
- Southampton, UK
Waterfall works well when you have work that is easily known, understood and done before. If you are doing anything new, it falls apart. It also very good at meeting contractual obligations that aren't actually what brings the most (or sometimes any) business value.
The only real way of writing safety critical software bug free is with formal methods, and that's incredibly hard at best. Good testing is not limited to only waterfall projects. Agile has requirements for this to be fast, and we like to automate as much as possible but ultimately this has less to do with the project management methodology.
Waterfall is very good at giving you a false sense of security on this. Bugs will always get through and being able to find and fix quickly is by far the better approach. Agile methods don't preclude good testing, but it should be fast to get quick feedback.
Again, a lot of this is a false sense of security. Take aircraft that are easily hackable due to the waterfall and certification methods which mean that vulnerable security software can't be updated without recertification. Google Chris Roberts or click link (https://edition.cnn.com/2015/05/17/us/fbi-hacker-flight-computer-systems/index.html)
This is the exact opposite of the situation. Agile works very well for small simple projects where the path to the goal is obvious and rapid iteration without planning will most likely lead to sufficient solutions, and failure is of little concern. For larger and more complex projects it fails, horrifically in some cases. Business value require meeting contractual obligations.
I don't think Agile is the real problem. It's the misconception that anything which isn't a waterfall methodology is agile. People hacking stuff together with no real plan, making it up as they go and claim they are following an agile approach.
There is also the misconception that whatever is not agile is "waterfall', w and is reminiscent of the 1960s software process. traditional software development processes matured, and are quite diverse. nothing in the Agile manifesto was knew, it was just re-spun into a fad
Man of Honour
- Joined
- 17 Nov 2003
- Posts
- 36,746
- Location
- Southampton, UK
Good quality software will fail less often. Waterfall doesn't help give better quality software though.
Agile working is all about doing small parts of a larger problem to help derisk it. It does not mean little or no planning.
Large and complex projects often fail due to the fact they are large and complex, not because of the project management methodology. Software engineering is more like landscape gardening than civil engineering which so much of the methodologies are taken from.
Yes, but the slow nature of legalities mean that these are often obsolete requirements as soon as they're agreed.
It's interesting that it raises 6 points:
Distributed teams - irrelevant to the methodology, this is a problem in both waterfall and agile.
Scaling Agile - this is often a problem due to software architecture that many large organisations use. Most existing systems are monoliths and so scaling any team to be able to maintain that codebase is difficult. Again, this is less about project management methodology and more about loosely coupled, tightly bounded systems that make changes less risky as they can be understood in their entirety.
Documentation - I would comment on this, but I downloaded the report that that link you provided is based on. It doesn't explain why they thought lack of documentation was a causal issue to projects failing or even if lack of documentation in agile projects was a problem. In fact it doesn't really talk about it except in the conclusions. Agile does not mean no documentation nor to avoid updating docs. It just says working software is more important than having comprehensive docs.
The only thing that report actually usefully draws attention to is the lack of architecture that is used in system design. This is a problem in many organisations regardless or how they plan their projects and is key to getting the loosely coupled, tightly bounded systems that enable so much good practice.
I think this is one of the key take aways. Agile is a value preference, not a methodology in itself. Many use SCRUM and agile interchangeably - incorrectly. I bet out of those companies that were part of the 6point6 report many think that splitting up a Gantt chart into 2 weekly sprints is 'Agile' and wonder why it's not working.
Soldato
- Joined
- 31 May 2009
- Posts
- 21,457
Surely thee comes a point they roll back, and add the last weeks transactions manually from their backups?
- such as over a bank holiday weekend where they have 72 hours of go time.
- such as over a bank holiday weekend where they have 72 hours of go time.
There comes a point in some upgrades where a rollback isn't feasible any more ... more so if it's significant re-platforming. Sounds they are in in a state where they just have to keep moving forwards. Am sure the execs asked at a very early stage for them to roll back and got the above answer.
It's unforgivable at this level however you've got to feel for the project team. The moment when things started to go south will have been particularly galling....
Bit surprised at that given they supposedly called in IBM who have a pretty decent "hit team" who can pretty much implement a complete solution for this almost on the spot (even with all the data recovery/verification issues that will be needed here) - maybe they don't want to pay what that costs though.
wat???
implement a complete solution on the spot... doubtful
having worked with IBM on a project (for IBM) the technical people I was exposed to left a very different impression. At least I got to stay in London while working on it, some people ended up in some bum**** town in New York State where 99% of the population are IBM employees.
You are taking me too literal - hence the "almost" - obviously they aren't going to turn up, implement and be gone in an hour. Dunno my experience has been different to what you are talking about - though we are talking about a lot of money and Z series implementation maybe its different at smaller scale but they seemed capable of rapidly scaling a solution up at almost any level.
EDIT: Obviously I don't really have any experience behind the scenes, etc. and I wasn't directly involved but they seemed pretty effective at recovering from what was pretty much a disaster albeit it wasn't cheap.
Soldato
- Joined
- 31 May 2009
- Posts
- 21,457
Is this not resolved yet?