please empty your brain below
|
The first half of this century will be remembered for software being the cause for (major) projects to overrun.
Maybe in a few decades time we might learn how to correctly scope, budget & write software.
Jon Jones | 23.11.21 - 8:21 a.m. | #
|
|
Thoroughly informative — far more so than anything I will read in the mainstream media on this topic. Thank you.
hemsl | 23.11.21 - 8:28 a.m. | #
|
It's interesting that a mega-project like this ultimately hinges on software delivery. Particularly when software is deemed to be the answer to everything. Perhaps it isn't.
It would be interesting to know the causes of the software issues - e.g. poor specs, poor coding, poor change control etc. Whatever the case, the scale of the challenge is obviously enormous, and they have my sympathy. It does seem that there is a lack of appreciation of how mega-projects seem to scale - the complexity is not linear, but geometric! So risks and issues are greatly more likely!
Chris L | 23.11.21 - 8:30 a.m. | #
|
|
I’ve been working in technology for years and seen how software development projects have not improved. However they have delivered a steady stream of novel phrases to avoid saying ‘late’.
Hanser | 23.11.21 - 8:38 a.m. | #
|
|
Will Lizzie live long enough to see the opening of her line?
Blue Witch | 23.11.21 - 9:03 a.m. | #
|
|
All planning is for the first day of service to be Sunday 6th March and everyone seems fairly confident that will happen. However, if trial operations does not go roughly to plan then it might slip, hence the vague six month window.
TfL worker | 23.11.21 - 9:08 a.m. | #
|
We tend to forget that modern trains are just some software with wheels and motors attached. This approach has some real benefits such as better monitoring of issues, flexibility of the solution and quicker fixes, and so this approach gives a much better train, but ignores the problem that you have to get the software right to make it all work. We have replaced the problems of mechanical and electrical engineering with software engineering problems, and our tools for doing software engineering are still not good enough.
Is this move to software-controlled solutions better than the traditional approach? The problem is that software controlled solutions enables you to add lots of new features and those features become embedded in the requirements, so the only possible solution becomes software controlled. I work in the IT industry and you see this everywhere. The added complexity creates lots of new jobs but projects take longer and cost more, so is the extra complexity worth the (sometimes minimal) benefits?
Jimbo | 23.11.21 - 9:12 a.m. | #
|
|
It appears that 'software issues' are now regularly blighting the completion of railway infrastructure projects - both large and small. A recent example was the reopening of the modest stretch of railway line on the Isle of Wight earlier this month, which was six months later than planned due to...software problems with the new trains! When Crossrail will finally open is anyone's guess and, when it does, it seems that it will initially be in three separate sections rather than one cohesive whole.
Carllo | 23.11.21 - 9:25 a.m. | #
|
|
Not only do the new features get embedded in the requirements, they also get embedded in the supply chain. So it becomes impossible to build a train, or a railway, the "old way", because "you can't get the parts".
Malcolm of Kent | 23.11.21 - 9:48 a.m. | #
|
As an example of how difficult these modern software-controlled solutions are, my company is assisting with a solution to monitor doors in stations (not Crossrail but elsehwere on the network). In a large, city-centre station, there are hundreds of doors, and if they stop opening or get blocked, it can cause serious issues many of which are safety related. So an "easy" solution is to add a sensor to the door opening mechanism to check how long it is taking for the doors to open and close - if they take too long, this is probably an indication that the door is failing, so send an alert to an engineer to have a look. A door sensor, a 4G modem, an engineer with a smartphone and a bit of software, and hey presto, a "simple" solution to the problem.
Accept, it is not as easy as that. Each sensor needs a good 4G or WiFi signal, so now we need to add repeaters in various places and because this is now part of safety critical hardware, you have to ensure the repeaters are working by monitoring on them as well and adding redundant devices. Another problem - how do you tell whether a door is stuck open or just remaining open because it is rush hour? Get it wrong and the engineer is wasting their time trying to fix non-esistent problems. Similarly, how do you ensure the door stays open and doesn't alert if there is an emergency? Easy, link it into the emergency alert system, adding lots of dependencies betwen systems. How about using machine-learning to monitor failures and identify weak or out of spec components? Great idea, but that has just added 4 more layers of complexity and cost on a "safety critical" system.
Alternative solution - get station staff to go around and check doors periodically. This means having the staffing costs (which may be cheaper than the above solution) but also means there might be delays in finding and fixing a "safety critical" issue, and that is no longer acceptable.
This kind of narrative is repeated across all the systems in the stations and trains. My guess is that many of the delays around Crossrail could be traced back to new safety requirements that weren't there before software control was a thing.
Jimbo | 23.11.21 - 9:55 a.m. | #
|
Yes, a good summary of far too many documents for the rest of us to read.
I think the problem is that the first electronic computers were only built in the 1940s. Software development is a very young industry. By contrast, the laws of mechanics or properties of electrical systems are well-understood due to centuries of discovery.
It seems that all the time there is a better software methodology or computer language to learn. We are really just infants trying to find our way about in a rapidly-changing new field that didn't exist 100 years ago. The positive of software is that once you get it up and working it is wonderful and it doesn't wear out.
Another question to ask is would Crossrail have even been possible without software? Yes, the Underground exists but it would be built afresh today and effectively relies on grandfather rights. Bank Station Upgrade and the Battersea extension has masses of software but they are on a small scale.
Pedantic of Purley | 23.11.21 - 9:55 a.m. | #
|
|
Such an interesting post. Also the comments. Jimbo's example is great, something you see happening on smaller scales all over.
Jayne | 23.11.21 - 10:25 a.m. | #
|
Given the drop in passengers, the finances have already gone in the shredder, TfL's latest bus consultation contains the following, which I think also applies to tube and rail.
'Demand on many central and inner London (bus) routes was declining prior to the coronavirus pandemic, and while the pandemic’s long-term impacts on demand are currently unclear, ridership is not expected to fully return to pre-pandemic levels in the near future.'
Still Anon | 23.11.21 - 11:41 a.m. | #
|
An over-riding concern about these and so many other systems is the absolute need for continuity of electricity supply. All the interlinked control and safety systems are useless if the power goes off — presumably why London Transport had its own power stations in the first place, even if that was just to keep the trains moving.
As an example, BT is clandestinely phasing out landline phones in favour of VOIP technology. The current hard-wired phone system is resilient: if there’s a power cut or emergency it keeps working. But with the new system — reliant on routers and wifi — if the electricity goes off, no conventional phones will work, and experience (the London bombings) shows that mobile networks fall over when everyone tries to phone at once.
Labourer | 23.11.21 - 12:42 p.m. | #
|
Software controlled railways have been with us since the late 1970's. And often problematic since then.
One of the early examples is BART in San Francisco, which operates similarly to the DLR but is much larger and faster.
An early iteration of the combined train and signalling for BART was built by a UK IT company, Logica--smart people who had a lot of problems making it work but got there in the end, but I think unprofitably. Hardware obselesence and system expansion meant that system has been replaced at least once since. Logica now long gone.
MilesT | 23.11.21 - 12:59 p.m. | #
|
Jimbo’s point is that the software is just one component (and arguably the easiest) of a complex system that needs thousands of interfaces with the outside world. Each of these is in itself a relatively simple mechanical and electrical device, and each seems a good idea at the time. When the number of these becomes too large the system becomes very difficult to manage.
Will it be possible to say ‘no’ to features that individually are a good idea, but collectively threaten to scupper the whole project?
RogerB | 23.11.21 - 2:33 p.m. | #
|
|
For most of it's life the railway system in this country operated with a simple idea of a carriage door with a handle. It worked and people travelled safely using it. Software systems are not all they are cracked up to be!
Tones | 23.11.21 - 2:48 p.m. | #
|
Those with better memories than mine will be able to recall how many people were killed falling out of HSTs before the central locking was installed.
Those in the know will be able to advise if this system had to interface with anything else - I suspect not.
RogerB | 23.11.21 - 3:49 p.m. | #
|
After all the comments about software causing the delays, it is worth re-stating that "station construction is no longer the critical issue it used to be."
Hard physical works of construction are still taking place on stations which were meant to be open in December 2018 (36 months ago) and therefore should have been completed at least 42 to 48 months ago!
The real scandal here is that there was gross misreporting of both progress and cost at the highest level but no-one has been held to account for it.
strawbrick | 23.11.21 - 7:29 p.m. | #
|
Yes, I think anyone suggesting that software is completely to blame for the delay ignored the fact that most of the stations weren’t finished either.
The short lead time before the announcement of the project being delayed wasn’t some new issue with software, it was poor management of the whole thing.
However there’s also many trains out there that need regularly rebooting. But they don’t exist on a very short headway service in a tunnel, so if they need to spend an extra minute rebooting at a station stop, that’s “acceptable”.
Kirk | 24.11.21 - 7:27 a.m. | #
|
|
Switching the trains off and on again was pretty much how the Class 458 Juniper trains were operated for the first few years by SWT. Appalling reliability when introduced, I sat on many a dark, stopped train, but by the end of their service they were the most reliable trains in the UK. We just have to get through the first 3-4 years of modifications and software updates.
Eddie Cochrane | 26.11.21 - 11:27 a.m. | #
|
Mid-January, and...
a) TfL confirm it will start in the 1st half of 2022.
b) Canary Wharf's still not been handed over.
diamond geezer | Homepage | 18.01.22 - 8:27 p.m. | #
|
|
|
TridentScan v2.10.0 | Privacy Policy
|