You've got the argument the wrong way around. Architects don't test like software developers do because they can't. They'd probably love to if they could, but because they can't, they're forced to do incredibly expensive and rigorous testing beforehand.
Software developers can test once we've built, and change what we've built easily, and try out things on real users and see how they actually use it. It's a massive advantage that we have over architects, that we should celebrate :)
Thanks, Marcus for your feedback. My intention was not to advocate for avoiding any change of software, and not do A B testing or agile adoption over time. I suffer on a daily basis because of zero tests included in a project I interact with. Mostly this code was done in a rush and first time actually tested on production. Also, the leak of tests cost the company a huge amount of money + time, since they have to pay manual QA. I still believe we can learn something from pedant architects, not really copy paste, but get some discipline out of that.
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.
You've got the argument the wrong way around. Architects don't test like software developers do because they can't. They'd probably love to if they could, but because they can't, they're forced to do incredibly expensive and rigorous testing beforehand.
Software developers can test once we've built, and change what we've built easily, and try out things on real users and see how they actually use it. It's a massive advantage that we have over architects, that we should celebrate :)
Thanks, Marcus for your feedback. My intention was not to advocate for avoiding any change of software, and not do A B testing or agile adoption over time. I suffer on a daily basis because of zero tests included in a project I interact with. Mostly this code was done in a rush and first time actually tested on production. Also, the leak of tests cost the company a huge amount of money + time, since they have to pay manual QA. I still believe we can learn something from pedant architects, not really copy paste, but get some discipline out of that.
Thanks for accepting my feedback.
I don't mean to imply that testing isn't important. It's very important. But this "architecture" metaphor isn't working for me ;)
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.