4 ms·

That’s an interesting viewpoint, in my experience almost 100% of budget overruns and ensuing lack of quality comes from changing requirements or rather truly th

That’s an interesting viewpoint, in my experience almost 100% of budget overruns and ensuing lack of quality comes from changing requirements or rather truly thinking through the requirements for the first time after the project is about halfway done. It would be my dream to work on a project that has everything figured out upfront, alas unlike bridges, every software project is pretty unique, otherwise why are you rebuilding something that’s already done?

jrochkind1 8y ago
Yeah, I don't think software changes are actually cheap at all. The difference is, I think, more that we are for whatever reasons better at predicting our true bridge requirements than we are at predicting our true software requirements. Which the OP discusses some.
taeric 8y ago
Oddly, most truly disastrous projects I have seen, have had no small amount of over engineering. There has been a bit of not understanding the requirements. But more is in not understanding current personal capabilities or needs. Think of it as training for a marathon. At the end of the day, it is knowable how many calories you will need to burn and how far you are going to run. You are still far more served by running several five and then ten kilometer races, than you are studying the marathon track you want to run. Similar goes for software. Make a few customers happy. Then more. Then more. Don't stall out thinking you need to be at Twitter scale for day one. Not even Twitter did that.
- sgt101 8y ago
  I've seen this too. My conclusion is that this happens when people who are strong communicators and networkers - influential even if they don't think of themselves that way - either misunderstand the need or value of some component, or they wilfully use the project to do a thing that they personally want to do. This "project as a vehicle for something else" is really catastrophic and is often a way for someone to exit the organisation with a gilded CV. What's important is that it screws everyone else. On the other hand, the obsessed super engineer is not being malicious, they believe wholeheartedly that they are right. The thing is to recognise which is which... one is a cancer that must be cut out fast, the other is a hugely valuable contributor who is misaligned (and in this case much listening is in order as it might be the project is misaligned).
- Retric 8y ago
  Twitter also failed regularly. The cost of failure varies, but in government work their are non zero risks of your failures making national news. For example the healthcare.gov’s failure the scale. Twitter only scaled well when they started over rather than trying to use Agle to bolt on add hock solutions.
lmm 8y ago
In my experience disastrous projects come of spending too much time thinking through requirements and not enough time actually validating them - what's perceived as "changing requirements" is more often than not actually a case of misunderstanding the requirement in the first place. Dozens of people in months of meetings can very easily specify something that is obviously impossible as soon as someone spends 5 minutes with a working prototype. That's why I've found Agile so much more effective - if you get a system that works end-to-end at the earliest possible stage it becomes so much clearer what's possible and what's not, and your design discussions are much more productive. You still have to make design decisions and tradeoffs, but you get to make them much later on when you have much more information to work with.

jrochkind1 8y ago

Yeah, I don't think software changes are actually cheap at all. The difference is, I think, more that we are for whatever reasons better at predicting our true bridge requirements than we are at predicting our true software requirements. Which the OP discusses some.

taeric 8y ago

Oddly, most truly disastrous projects I have seen, have had no small amount of over engineering. There has been a bit of not understanding the requirements. But more is in not understanding current personal capabilities or needs. Think of it as training for a marathon. At the end of the day, it is knowable how many calories you will need to burn and how far you are going to run. You are still far more served by running several five and then ten kilometer races, than you are studying the marathon track you want to run. Similar goes for software. Make a few customers happy. Then more. Then more. Don't stall out thinking you need to be at Twitter scale for day one. Not even Twitter did that.

sgt101 8y ago
I've seen this too. My conclusion is that this happens when people who are strong communicators and networkers - influential even if they don't think of themselves that way - either misunderstand the need or value of some component, or they wilfully use the project to do a thing that they personally want to do. This "project as a vehicle for something else" is really catastrophic and is often a way for someone to exit the organisation with a gilded CV. What's important is that it screws everyone else. On the other hand, the obsessed super engineer is not being malicious, they believe wholeheartedly that they are right. The thing is to recognise which is which... one is a cancer that must be cut out fast, the other is a hugely valuable contributor who is misaligned (and in this case much listening is in order as it might be the project is misaligned).
Retric 8y ago
Twitter also failed regularly. The cost of failure varies, but in government work their are non zero risks of your failures making national news. For example the healthcare.gov’s failure the scale. Twitter only scaled well when they started over rather than trying to use Agle to bolt on add hock solutions.

lmm 8y ago

In my experience disastrous projects come of spending too much time thinking through requirements and not enough time actually validating them - what's perceived as "changing requirements" is more often than not actually a case of misunderstanding the requirement in the first place. Dozens of people in months of meetings can very easily specify something that is obviously impossible as soon as someone spends 5 minutes with a working prototype. That's why I've found Agile so much more effective - if you get a system that works end-to-end at the earliest possible stage it becomes so much clearer what's possible and what's not, and your design discussions are much more productive. You still have to make design decisions and tradeoffs, but you get to make them much later on when you have much more information to work with.