Testing provides confidence
You only guess that your architecture will work by looking at diagrams or source code
Most software projects are subjected to a decent amount of testing. Unit testing, integration testing, system testing, user acceptance testing, operational acceptance testing and so on. All of this this happens because testing provides confidence that the software will work as expected. For some reason though, we don't tend to evaluate that our architectures will work from a number of other perspectives. For example, can you tell if the following software systems will perform and scale acceptably?
No, of course you can't, yet few people actually take the time to ask this question, let alone answer it.
Familiarising yourself with the static characteristics of a software system is easy to do by looking at the code, working with the code or reading high-level documentation. The runtime characteristics though, are often complex and somewhat intangible. Executing the code is often the only way to truly understand aspects such as resource utilisation, threading and deadlocks, whether connection pools are tuned correctly and so on.
If performance and/or scalability are important for the types of software systems that you build then you owe it to yourself to prove that your architecture works as early as possible to prevent any nasty surprises when it's too late. You only guess that your architecture will work by looking at diagrams or source code. Testing it will provide the real answer.
