Hacker News Reader

Comment by nbevans | Hacker News Reader

Indeed - the expectations were very high for Crossrail before and during development. All that has happened is they have delivered the product exactly as described, albeit 4 years later and over budget.

It should be noted that 4 years ago the BBC were running documentaries about how successful the Crossrail project had been after the tunnels were finished and most of the stations were almost done. It seems that nobody expected the software and signalling to take an additional 4 years of time. Somebody somewhere really messed up that part of the project. Everything else - the main civil engineering project - did go extremely smoothly and was even ahead of schedule at times.

View on HN

It didn't help that about 4 years ago, just before it was due, they were declaring it was going to be one of the few projects that was going to be delivered on time and under budget, and only caved at the last minute.

It’s not like software engineers to underestimate how long something will take :)

How do we fix it though? I empathise with the developers involved - there’s an inclination to look at what they had to do as just engineer some software to manage some signals, some diagnostics and some trains. And to some extent that’s true but it overlooks the other part of their process which is more akin to painting a great artwork - when will you be done with that?

I frequently see one answer fail - we just need to plan it more thoroughly, don’t just estimate, go through exactly what you’ll need, identify dependencies now not during coding. These efforts always fall for the same reason, when it comes time to implement, the plan is hopelessly out of date, incomplete and just plain naïve.

It’s easy to deliver software on time up to around 10kLOC (i.e. single developer short project). Beyond that, the variables cascade and avalanche exponentially. The problem with this is all the interesting problems need >1dev and certainly more than 10kLoc!

On balance I’m more persuaded by XP than by Royce but honestly i don’t think either approach makes or breaks, both can work well.

It was a highly complex integration of 3 different railway signalling protocols. These are safety critical systems that need to be "proven" to be safe through extensive simulation tests and real-world testing. The Crossrail/Siemens team that worked on this integration split the project up into 4 parts. 3 parts for each signalling system. And then the final part to allow transitioning a train between each signalling system in a seamless way. They were testing the trains on the western, central and eastern parts of the line for years as a way of gaining confidence in their work. It has been reported that this is the first time anywhere in the world that a railway has been created to support multiple signalling systems and be able to transition seamlessly between them during service.

I disagree with the artwork analogy. I think it’s quite easy to decide when a software project is “done” if you set the requirements in detail at the beginning.

I think the issue plaguing estimation of projects is that a lot of software development involves running into problems and trying to solve them. Sometimes figuring out solutions to these issues is difficult and solutions appear as if by magic (in this was the art analogy makes sense in terms of inspiration). I’m not sure how we can ever estimate large projects accurately while we often need these moments of inspiration in order to solve problems.

>> if you set the requirements in detail at the beginning

How do you do that though? If we’re only talking about nailing down requirements (so lets ignore the problem of dependencies for now), then a 300 page BRD buys you enough spec to gainfully employ 4 devs for maybe a month-ish? I’m going off fin reg style work, i have no idea how that might translate to civil engineering so my numbers might be well off?

The BRD wasn’t free to produce, it contains 3-9 errors (assuming human rate of error is 1 to 3 in 100), and it’s being updated to v2 as you’re working.

How is this getting us all to the overall goal with predictable timing?

Oh I bet plenty of engineers knew the estimates weren't right. I've seen cases where people don't point this out to management because they expect if they do management would just put htem under more pressure rather than getting the timeline right.

My understanding is that the train software got built, more-or-less, according to the spec given, in a synthetic environment.

The problem is that in real-world testing, conditions around the changeover points produced behaviour that was not addressed by the spec. It turns out that dealing with radio-based systems in the middle of a busy rail network in the middle of a city is really hard. Many of the problems were caused by radio interference in the area. It's definitely the sort of problem practically nobody on this forum works on.

> It seems that nobody expected the software and signalling to take an additional 4 years of time. Somebody somewhere really messed up that part of the project. Everything else - the main civil engineering project - did go extremely smoothly and was even ahead of schedule at times.

I understand software and signaling took extra time, but those drove the costs too? Compared to the rest, they don't seem expensive.

Reply on news.ycombinator.com