3 ms·

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 mana

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.

nbevans 4y ago
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.
basisword 4y ago
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.
- CraigJPerry 4y ago
  >> 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?
trebligdivad 4y ago
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.

nbevans 4y ago

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.

basisword 4y ago

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.

CraigJPerry 4y ago
>> 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?

trebligdivad 4y ago

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.