Most developers understand testing strategy as something which comes to the end of the development process and usually done manually by the developer itself or QA. Because not everybody sees a problem here, let’s take a parallel journey with architects and observe how they build a building.
Build a building like a software developer
Would you believe that architects build a whole building and then step aside and observe stability after construction worker did their job? Alternatively, build construction and then let it stay empty for a couple of months with test inhabitants inside. In that period architect can observe all factors such as stability, basic usability, material quality, etc. Then a couple of months later she/he introduces her/his building to the actual inhabitants and then, let them discover all malfunctions, problem, misplaced doors, not working electricity, etc. To don’t mention more serious problems they can find, such as way too thin walls, a floor which can’t handle the weight of their bookshelf, etc.
Integration
Well, none of this happens in architecture, but it happens all the time in software development. I saw so many times software being developed, and first time tested after the development cycle being done. Architects do not do that. They have formulas and rules which make them put any construction on test way before they start to build it. Construction is made out of many pieces, concrete blocks, etc. All of this peaces put together interact whit each other and change the behavior of whole construction. Architects know exactly what is forces and momentums between two elements way before they put them together in reality.
This could be compared with integration tests in software development. You have a bunch of components which together should form a construction, every component may have different properties, but what is important is that output of one component is an input of a second one, and they should be in harmony
Unit
Construction is made out of single elements. Every single element has his own properties. Architects know in advance what materials they can use, what is the projected weight of an element, what will be capacity and strength of every single element inside construction. This is something very similar to unit tests in software development. Unit test makes sure that every part of construction can handle tasks they are designed for. They are simple static formulas in architecture, which ensure that behavior of every single element stays same all the time. If you make one element weak, then your integration tests should show you a problem, but a unit test is the one which shows you exactly which single element is weak.
Functional
Architects do not need an actual human to enter the building and start using it to discover that she/he puts power slots in places impossible to reach, doors which not going anywhere, windows which can’t be open. They have a set of standards for everything, electricity, placement of doors, lights, etc. Where standards do not help they can use common sense. Software developers can make a set of functional tests, which works with an actual database, mimic user journey and predict common paths of users, way before putting software in actual use.
Personal note
I suffer on a daily basis because of zero tests included in projects I interact. Mostly this code was done in a rush and first time 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 copy paste, but get some discipline out of that.
Top comments (14)
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
Some comments may only be visible to logged-in visitors. Sign in to view all comments.