So I only grew up and then worked in the architecture firm my parents had, but let me tell you, no portion of mass infrastructure should be done fast, it should be done RIGHT. That software is more sand-box in premise doesn't excuse not having rigorous testing :) Fast software development gets you Fallout 76's and the inaccessible mess that is Gutenberg.
Developers are increasingly making software that society is reliant on and if that should continue (properly) it should require 99.9%+ uptime and much, much, much, more rigorous standards than currently. Resting on the "we can fix it later" laurels is so empty, intention-wise, because you're already starting from a point of "it'll do", and as projects get more and more complex, the care/efforts start to dwindle.
This comparison between the construction industry and the software industry always comes up, and it's always wrong.
Once you've built a building, you can't change it easily. This is not true of software.
The biggest problem in building software is not writing the code, but understanding the problem. It is often massively easier to build a throwaway prototype to understand the problem, and then build a "real" version with much better understanding of the problem, than it is to collect all the requirements in the first place.
This isn't an option open to architects. There are lots of options that are not open to architects. The two industries are very different, for very good reasons.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So I only grew up and then worked in the architecture firm my parents had, but let me tell you, no portion of mass infrastructure should be done fast, it should be done RIGHT. That software is more sand-box in premise doesn't excuse not having rigorous testing :) Fast software development gets you Fallout 76's and the inaccessible mess that is Gutenberg.
Developers are increasingly making software that society is reliant on and if that should continue (properly) it should require 99.9%+ uptime and much, much, much, more rigorous standards than currently. Resting on the "we can fix it later" laurels is so empty, intention-wise, because you're already starting from a point of "it'll do", and as projects get more and more complex, the care/efforts start to dwindle.
This comparison between the construction industry and the software industry always comes up, and it's always wrong.
Once you've built a building, you can't change it easily. This is not true of software.
The biggest problem in building software is not writing the code, but understanding the problem. It is often massively easier to build a throwaway prototype to understand the problem, and then build a "real" version with much better understanding of the problem, than it is to collect all the requirements in the first place.
This isn't an option open to architects. There are lots of options that are not open to architects. The two industries are very different, for very good reasons.