What are the reasons for rebuild and redeployment libraries?

Question

It's difficult to understand the meaning of the question from the topic's name.

Here is what I mean.

I'm watching Uncle Bob's Clean Code Episodes. In many episodes where he is talking about SOLID principles he mentions the problem of rebuild and redeployment caused by code changing. He says that bad architecture causes frequent rebuilds and redeployments.

But I have a couple of questions:

1. Why frequent rebuilds and redeployments is bad?

2. Can you enumerate causes of rebuilds and redeployments of dll's?

3. Is there any difference between different languages according to the second question?

4. What causes rebuild and redeployment of dll's in C#?

The second question (and the most common) is based on dll's coupling. What should I change in one of two coupled dll's so then I have to rebuild and redeploy the other?

Answer 1

1. Because it's extra work, and a source of potential errors. If you don't have to deploy, there is no possibility of error in the deployment process. Deployment can be expensive if you have to take down one or more servers to do it.

2. Anything that changes a DLL will cause a rebuild and redeploy. Specifically, if you make a change to the DLL's code, you will need to rebuild and redeploy it (assuming the change is a significant and desirable one).

3. Some languages like Erlang have "hot deploy" capabilities, which means that you don't have to take down the server or device to deploy changes. This is useful for things like phone switches and traffic lights which must be running 24x7.

4. See 2.

Bad architecture, from Uncle Bob's point of view, means that the code is too tightly coupled. Code that is too tightly coupled causes increased rebuilds and deployments, because your code has too many dependencies on other code in other DLL's. Consequently, making changes to one DLL often cascades into changes required in other DLL's.