7 ms·
It's kind of curious coming out of university where I learned about doing requirements properly and up front (which I suspect kind of tends towards a waterfall
by onei 7y ago
It's kind of curious coming out of university where I learned about doing requirements properly and up front (which I suspect kind of tends towards a waterfall approach) then comparing that approach to my work now.
Project managers constantly change their mind about requirements and then wonder why we're shipping late, although I suspect some of this is not considering failure/bugs when planning. Even when it comes to breaking down and estimating work, if the estimates software engineers produce don't align with the high level schedule they're automatically wrong or people start asking about what we can trim down (which somehow is always testing).
Perhaps it's idealism vs reality, but I find it a bit bizarre.
- szatkus 7y agoBecause it's much easier to change software than for example a bridge. I don't see it as a bad thing as long as all sides are aware that changing requirements changes the deadline as well.
- reallydontask 7y ago> I don't see it as a bad thing as long as all sides are aware that changing requirements changes the deadline as well. In my experience, this could not be further from the truth. There is simply no awareness that change remains expensive it's just that now the process allows it without any fanfare whereas before a change was a big deal. Not saying that change requests are the way to go but certainly an understanding that change is not free would go a long way
- iainmerrick 7y agoChange in a software project definitely isn’t free but I do think it’s fair to say it’s easier than changing a bridge design halfway through. Maybe there’s not as big a difference as people think, though? It occurs to me that is actually possible to change the design of a bridge late in the day. The extra dampers to fix resonance problems on London’s Millennium Bridge are a nice example.
- peteradio 7y agoI think there is a bit of respect for the bridge building process not to change it half way through on a whim.
- iainmerrick 7y agoOr maybe bridge engineers are better at pushing back on change requests. (I don’t actually know which it is; maybe it’s both)
- bilekas 7y ago> I don't see it as a bad thing as long as all sides are aware that changing requirements changes the deadline as wel It's extremely dangerous, and software is quite comparable to a bridge. Imagine starting at both sides of the river and the bridge not meeting in the middle. Changin requirements / features is very simular. And while on paper it sound like no problem, thats when you need to push back against your PO/Whoever is pushing the change.
- szatkus 7y agoYes, there are some analogs to bridges, but software is much more flexible than concrete. We can pretend we're building a bridge, but there could be another company, that is more comfortable with changing requirements and may deliver their product later, but more suited to a market.
- TheOtherHobbes 7y agoSoftware isn't more flexible than concrete. Software looks as if it should be more flexible than concrete. But it really isn't.
- AstralStorm 7y agoOnly some software is that flexible, and then that flexibility will end with the end of support time. Ultimately all software becomes very inflexible if you cannot get the source code or especially flash firmware.
- bluGill 7y agoThey are building a bridge over the river near me. Headlines a month ago where that the two ends were within half and inch (1.25cm) of each other - which was considered the best possible case. Last year the bridge contractor build a dozen different adapters plates so cover all possible mismatches so that construction wouldn't slow down when the two ends got close enough together that they could tell how far off they were. (the bridge was supposed to open 5 months ago, but that is a different story...) I'm not sure what the point is, but it somehow fits into yours...
- C1sc0cat 7y agoBridge tolerances are measured in cm, and I suspect that the contractor does make changes on site from the original design the consulting engineers delivered.
- zcw100 7y agoIt doesn’t bother me when they change their mind. What bothers me is when they refuse to document it. Every change should be documented. Print it out and get them to sign it. Then when they complain whip out your pile of documents and say, “Here’s where you asked for X, changed your mind to Y, then back to X, then something new to Z. Is that your signature?” Devs are expected to have a ticket to track everything they do, so should the product managers. There should also be tickets for meetings so I can track how much time was subtracted from development by useless meetings.