I think that the architecture analogy falls short in 2 respects:
Buildings are very hard to change after they have been built, compared to software
There is much more knowledge on how to build a house in general, compared to software development, where often it’s just “figure out what the customer wants / the solution as we go”.
That being said, I guess that’s not your main point. You are advocating a “build quality in” mindset during development - instead of waiting until the customer sees the product for the first time. Right? In that respect, I fully agree. In my experience, any non-trivial application will cause you huge pain in the long run without automated tests.
Hi Bertil, I agree with two bullet-points you wrote down. Unlike software, the building is stationary construction, not really agile, and yes, there is a knowledge base much deeper than in our industry. But as you mentioned my intention wasn't to point to unchangeable code, instead intention was to point out a leak of quality and responsibility during the development process. It is very hard to compare anything to architecture but not come hand by hand with the fact of "hard to change" the construction.
When it's come to a software change, adoption AB testing etc. analogy could be that architect can try out a couple of model of windows for the room until the customer is satisfied (not really happen much time in reality, but let's just imagine). Customer will still expect every time that window opens, he can see through the glass, it isolates him from outside word. That's what we can do with our software as well, we can change, we can change so easily, but we can always ensure that our new version still works as the customer expects.
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.
I think that the architecture analogy falls short in 2 respects:
That being said, I guess that’s not your main point. You are advocating a “build quality in” mindset during development - instead of waiting until the customer sees the product for the first time. Right? In that respect, I fully agree. In my experience, any non-trivial application will cause you huge pain in the long run without automated tests.
Hi Bertil, I agree with two bullet-points you wrote down. Unlike software, the building is stationary construction, not really agile, and yes, there is a knowledge base much deeper than in our industry. But as you mentioned my intention wasn't to point to unchangeable code, instead intention was to point out a leak of quality and responsibility during the development process. It is very hard to compare anything to architecture but not come hand by hand with the fact of "hard to change" the construction.
When it's come to a software change, adoption AB testing etc. analogy could be that architect can try out a couple of model of windows for the room until the customer is satisfied (not really happen much time in reality, but let's just imagine). Customer will still expect every time that window opens, he can see through the glass, it isolates him from outside word. That's what we can do with our software as well, we can change, we can change so easily, but we can always ensure that our new version still works as the customer expects.