3 ms·
Because structural engineers work primarily with other structural engineers, or maybe (real) architects at best. You were insulated from the ultimate 'customer'
by repolfx 8y ago
Because structural engineers work primarily with other structural engineers, or maybe (real) architects at best. You were insulated from the ultimate 'customer' by at least one layer of profession, maybe more. You were also doing work that was safety critical which meant you had the final call and final veto, always, because you could say "that won't be safe" which is a debate-ending move.
Software engineers get to do "engineering" where they don't control their own deadlines, can be forced to launch at arbitrary unplanned times, where the customer can't explain what they want and what they want is always changing anyway, and they are effectively disempowered to fix any of this because they posess no debate-ending move like other forms of engineering do. And many other fundamental problems that make it a different kettle of fish altogether.
- phakding 8y agoStructural engineers do not work primarily with other SEs. They have to collaborate with architects. Architects tend to take lot of artistic freedoms when designing a structure. We get to tell them to shove it as implementing some of their artistic designs would involve defying gravity and other laws of physics. Although that doesn't work and then you get failed/delayed/extremely over budget project SEs also work with civil engineers/site supervisors etc. No there's no veto resides in hands of engineers in any industry. There's a reason why bridges collapse and buildings need to be tore down for safety. It's not because engineers got to decide what's right.
- repolfx 8y agoCan you show me cases where a bridge collapsed because the engineers on the project said "this will be totally unsafe" and were overruled by non-technical business managers?
- phakding 8y agohttps://www.usatoday.com/story/news/2018/03/16/miami-bridge-collapse-suspension-cables-support-tower/431418002/ https://www.usatoday.com/story/news/2018/03/16/miami-bridge-... http://www.ejinsight.com/20180406-hk-engineers-raise-concerns-over-safety-of-mega-bridge/ http://www.ejinsight.com/20180406-hk-engineers-raise-concern... There are many more, but the fact that engineer's safety concerns were side stepped rarely sees light of the day after disaster strikes. Also it doesn't have to be a catastrophic failure. Sometimes the reduction of life span of a structure is cause of not taking care of all the concerns. Also this does not stops with construction. Have you not heard about problems in cars or other engineering projects where safety concerns were ignored. If not, I have to ask you how old you are.
- repolfx 8y agoThe first story doesn't seem to support your point. It's talking about engineers saying a bridge was unsafe after it collapsed. Whilst a FIGG engineer seems to have reported that the bridge was collapsing two days before it did, what I'm talking about is where a senior engineer i.e. chief engineer on a project says "this design is not safe" and is then told to build it anyway, or where a bridge isn't finished on the day that was expected and then traffic is put on it anyway whilst the builders are still working. People realising they screwed up after disaster strikes is normal but unrelated to project management discipline. The second link has the same issue - the engineers cited as saying something is unsafe are saying that after problems are spotted and they are not the same people who built the bridge. Sure, anyone can say "that was clearly unsafe" after the fact. To repeat, what I asked for is cases where the engineering management of a project said "this is not safe" at the time they were being told to build it and non-technical management then overruled them and put traffic on it anyway, that is, the engineers were not allowed to complete the job to their own level of safety satisfaction.
- fenwick67 8y agoIt sounds like you're saying it's different because there's inherently more customer interaction with software, but I think that's not really it. Take for instance a car company. The mechanical engineers designing camshafts won't have a scrum team, but the people working on engine software probably do.