On the right number of methods, classes or DLLs in a project - or: Just cut a few and it will be perfect

Udi Dahan did a posting on a question he received from a developer the other day: The developer asked him, why Udi was so much in favor of so many DLLs in a project? Wouldn´t the large number of DLLs make the project unnecessarily complicated?

I agree with Udi´s response and I hear the same question, too, quite often. But it always reminds me of a dialog in the movie "Amadeus":

Emperor Joseph II: "Your work is ingenious. It's quality work. But there are simply too many notes, that's all. Just cut a few and it will be perfect."
Wolfgang Amadeus Mozart: "Which few did you have in mind, Majesty?"

As if there was a maximum to the number of notes in a musical piece - as long as it fulfilled its purpose to please. Too many notes is a rediculous concept.

But so is the idea of too many DLLs in a project - as long as it fulfills its purposes. Interestingly, I think the same developer would not have asked Udi, if there were too many classes in the whole project. He just saw more DLLs than usually and that made him uneasy.

There is no such thing as a maximum number of methods or maximum number of classes or maximum number of DLLs in a software project! It´s all about the right (!) number of software artifacts.

But what´s the right number of classes or DLLs?

To answer this obvious question we´ve to ask, what the purpose of software artifacts is. What´s the purpose of methods oder classes in general? What´s the purpose of a certain class or DLLs?

Methods combine statements to form a unit of function. Statements that belong together go into the same method. The same is true for methods forming a class. It´s a question of concerns. Put together what belongs together. Keep apart, what is sufficiently different. Low coupling, high cohesion should be the mantra of every software designer.

But that´s not so new, is it? It´s pretty well understood on the level of methods and classes. 15 years of OOP should have driven this point home.

However, developers lack a bigger picture of software. They lack established levels of abstraction above the class level. But there´s more to the world of software as the Software Universe and Software Cells model describe:

Method and Class are just the lowest levels of abstraction when designing software. So what Udi´s developer is lacking is a bigger picture and tools/concepts to manage complexity. Software is a polylogic entity, so trying to handle it by just reducing some number of artifacts is plain wrong.

Instead, we need to develop an awareness of the intersecting hierarchies (of different logical domains, e.g. structural hierarchy, logical hierarchy, derivation hierarchy) and also rules of how artifacts should or should not be delineated and connected in each of those hierarchies.

Each of those hierarchies with its logic can be viewed as a separate dimension in a n-dimensional Software Universe (of which the above picture only shows one dimension, the structural hierarchy) thus making software an n-dimensional concept. This might not sound very helpful, but in fact it is, because when the different "facets" of software are undenieable it is better to have a clear frame of reference for them instead of always mulling them together.

So what is needed is not fewer classes or DLLs, but rather models and tools to manage complexity. Software developers better get used to that. Because the complexity of software is only increasing as we move forward in our industry. So let´s get real: It´s not the number of DLLs that´s irritating some of us. It´s the lack of knowledge of how to manage them (e.g. with regard to deployment, dependency management, versioning, development).