Most developers understand testing strategy as something which comes to the end of the development process and usually done manually by the develop...
For further actions, you may consider blocking this person and/or reporting abuse
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 ;)
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.
Not sure about architects, but to me, Legos are a better analogy. Unit tests ensure the bricks don't fail. Integration tests check that the bricks and their interfaces combine nicely together. Acceptance tests ensure the kid's getting what they want every step of the way. If they don't like the look, the child changes things immediately.
The rest is the UX, which is where the reward of all that effort comes in.
Thanks for the feedback! You are 100% right! If I wrote the same thing but used LEGO as an analogy, I might avoid some misunderstanding :)
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.
"... what is important is that output of one component is an input of a second one, and they should be in harmony..."
Bingo.
Thank you so much for positive feedback + sharing this talk from Glenn Vanderburg, great guy, great talk. I learned and reminded myself of the waterfall :D