4 ms·

Why does software industry keep coming up with this sort of thing all the time? I worked as structural engineer before becoming software engineer and we never h

Why does software industry keep coming up with this sort of thing all the time? I worked as structural engineer before becoming software engineer and we never had to invent different kind of leadership and procedures or change office floor plans or hire outsider non-engineers as our (scrum) masters, or talk about the client as stake holders etc. Sorry about hurting your agile feelings!

DJBunnies 8y ago
Go you.
- phakding 8y ago
  This was the only comment you made in 8 months. I feel honored!
humanrebar 8y ago
Software is incredibly open ended. Maybe even more open ended than writing in English because software can be written in several languages or even in brand new ones. The lack of natural structure in the work means communication and collaboration among the development team(s) is all that more important.
- phakding 8y ago
  If you are choosing multiple languages for a single project or Keeping your project "incredibly open-ended" no amount of methodologies is going to stop you from going over the cliff.
- commandlinefan 8y ago
  Structural engineering, or any other kind of real engineering (which includes every time of engineering except software "engineering") can also be reduced down to pure math. It's complicated math, and not everybody can comprehend it, but what engineers do boils down to lots and lots of equations. The only place this really applied in software is in efficiency calculations: is approach _x_ faster than approach _y_? In general this is considered a waste of time by most of the "stakeholders" (that is, the people who are signing the paychecks), at least until it's too late.
  - yarper 8y ago
    Software engineering can be reduced to math too, for example functional programming is a lambda calculus derivative. I think it's basically just that we're so close to programming that it's hard to see it for what it is, just a bunch of rules and equations.
    - kthejoker2 8y ago
      That's just one facet of software engineering. Large swaths of it cannot be reduced to math ie everything the user actually sees, hears, perceives, etc. Those are subject to psychology, aesthetics, ergonomics ... Although we're trying to quantify those, too, so maybe one day ...
reciprocity 8y ago
It's not a bad question to ask. Structural engineering as a profession has also existed much, much longer than software development and with that comes new lessons of doing things better - perhaps at the expense of forgetting some of those problems have already been solved elsewhere. It's as if our industry has this undercurrent of desire to reinvent the wheel instead of learning from what history is so good at teaching (providing context). No idea how on the mark I am about this.
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 ago
  Structural 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 ago
    Can 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 ago
      https://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.
scarejunba 8y ago
Well, because we develop more value than structural engineers faster than they do and have killed far fewer people than they have. Essentially, we’re economically more efficient so a 10% improvement in our performance is huge, while a 10% improvement in structural engineer performance is a waste of time for the cost incurred. Therefore, software engineers get a lot more attention in terms of how to increase efficiency. The difference is akin to why there’s so much work to get CEOs to be more efficient but not that much work to get janitors to be efficient. It’s not a value judgment. It’s just economical reality.
- phakding 8y ago
  Sure bud! "We" developing more value (whatever that means) is equivalent to that of a stock trader on an open outcry floor thinking they develop country's economy.
  - scarejunba 8y ago
    Market value, not the abstract concept of value. Stock traders that make lots of money definitely count as developing more value in the sense I was talking about. That is, money earned to the firm.
- zb 8y ago
  A less glib way of putting this is that in structural engineering construction costs dwarf design costs, while in software engineering the reverse is true. If your construction phase consists of "type 'make' and grab a coffee" and the most expensive part is the coffee, then any efficiencies you can find in the design process will make a big difference to your bottom line. If your construction phase costs tens of millions of dollars, you'll want to invest in designing more efficient construction methods rather than worry about tweaking the design process.
devingoldfish 8y ago
Hey man, as someone who also formerly worked in a different industry, thank you for raising this question. The longer I'm in software development (six years now) the more confident I am that all the varying rationalizations for this stuff are complete BS. Please keep raising these questions so that those of us who don't believe in bizarre guru-based project management approaches can have a home in this industry.
thewileyone 8y ago
Hey, I've been in software forever. All this scrum, agile, new fangled terms is just work. Call it what you want, but it's all just work. Do work and you'll get done, no matter the process. Do great work and you'll never have to look at it again.

DJBunnies 8y ago

Go you.

phakding 8y ago
This was the only comment you made in 8 months. I feel honored!

humanrebar 8y ago

Software is incredibly open ended. Maybe even more open ended than writing in English because software can be written in several languages or even in brand new ones. The lack of natural structure in the work means communication and collaboration among the development team(s) is all that more important.

phakding 8y ago
If you are choosing multiple languages for a single project or Keeping your project "incredibly open-ended" no amount of methodologies is going to stop you from going over the cliff.
commandlinefan 8y ago
Structural engineering, or any other kind of real engineering (which includes every time of engineering except software "engineering") can also be reduced down to pure math. It's complicated math, and not everybody can comprehend it, but what engineers do boils down to lots and lots of equations. The only place this really applied in software is in efficiency calculations: is approach _x_ faster than approach _y_? In general this is considered a waste of time by most of the "stakeholders" (that is, the people who are signing the paychecks), at least until it's too late.
- yarper 8y ago
  Software engineering can be reduced to math too, for example functional programming is a lambda calculus derivative. I think it's basically just that we're so close to programming that it's hard to see it for what it is, just a bunch of rules and equations.
  - kthejoker2 8y ago
    That's just one facet of software engineering. Large swaths of it cannot be reduced to math ie everything the user actually sees, hears, perceives, etc. Those are subject to psychology, aesthetics, ergonomics ... Although we're trying to quantify those, too, so maybe one day ...

reciprocity 8y ago

It's not a bad question to ask. Structural engineering as a profession has also existed much, much longer than software development and with that comes new lessons of doing things better - perhaps at the expense of forgetting some of those problems have already been solved elsewhere. It's as if our industry has this undercurrent of desire to reinvent the wheel instead of learning from what history is so good at teaching (providing context). No idea how on the mark I am about this.

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 ago
Structural 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 ago
  Can 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 ago
    https://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.

scarejunba 8y ago

Well, because we develop more value than structural engineers faster than they do and have killed far fewer people than they have. Essentially, we’re economically more efficient so a 10% improvement in our performance is huge, while a 10% improvement in structural engineer performance is a waste of time for the cost incurred. Therefore, software engineers get a lot more attention in terms of how to increase efficiency. The difference is akin to why there’s so much work to get CEOs to be more efficient but not that much work to get janitors to be efficient. It’s not a value judgment. It’s just economical reality.

phakding 8y ago
Sure bud! "We" developing more value (whatever that means) is equivalent to that of a stock trader on an open outcry floor thinking they develop country's economy.
- scarejunba 8y ago
  Market value, not the abstract concept of value. Stock traders that make lots of money definitely count as developing more value in the sense I was talking about. That is, money earned to the firm.
zb 8y ago
A less glib way of putting this is that in structural engineering construction costs dwarf design costs, while in software engineering the reverse is true. If your construction phase consists of "type 'make' and grab a coffee" and the most expensive part is the coffee, then any efficiencies you can find in the design process will make a big difference to your bottom line. If your construction phase costs tens of millions of dollars, you'll want to invest in designing more efficient construction methods rather than worry about tweaking the design process.

devingoldfish 8y ago

Hey man, as someone who also formerly worked in a different industry, thank you for raising this question. The longer I'm in software development (six years now) the more confident I am that all the varying rationalizations for this stuff are complete BS. Please keep raising these questions so that those of us who don't believe in bizarre guru-based project management approaches can have a home in this industry.

thewileyone 8y ago

Hey, I've been in software forever. All this scrum, agile, new fangled terms is just work. Call it what you want, but it's all just work. Do work and you'll get done, no matter the process. Do great work and you'll never have to look at it again.