My client has a super Spaghetti codebase structure. Single solution with some hundreds projects in that solution, which are tightly coupled.

They think that just using a package manager (like NuGet) is a solution to their problem, they want to create packages from their codebase and put them in their internal repository, and they think it will solve all of their dependency and coupling issues. I believe that NuGet is just a Package Manager and it is not an architectural solution. Can Package Manager be considered as an architectural solution?

  • 5
    Well you're not starting with a good way to convince anyone. First, thinking of them as idiot gets in the way of figuring out how to communicate with them. Second, terms like 'is not an architectural solution' just sound like you're acting superior. So maybe start with some 'dumb questions', like what are the top problems we're having, and will nuget solve those? Maybe you can ask these questions in a way they will understand, and get them to have the brilliant idea of seeking another solution.
    – joshp
    Commented Nov 5, 2016 at 2:08
  • @joshp I like your comment. From their standpoint their top problem is their packaging issue. At first, they were in denial phase and could not believe that the system has Spaghetti structure. I provided them the full dependency map of their solution and visualized the issue, and describe them the "top problem". Now they are saying that they want to deal with this "top problem" after they are done with Packaging. Should I have this approach to say whatever, I'll do what they want and rest is their problem?
    – Fred Jand
    Commented Nov 6, 2016 at 18:17
  • 1
    Probably yes. It's their decision. They are paying the bills. Sometimes you have to move forward with what a client asks to build the credibility and opportunity to continue the dialog and show them there's a better way. Sometimes as a consultant you may not be aware of the full impact of problems on them. Sometimes those impacts are far from development. Simply having a more automated and repeatable deployment might reduce the pain and buy more time to make improvements, even if the product is a mess at the code level.
    – joshp
    Commented Nov 6, 2016 at 20:38

1 Answer 1



All a package manager like Nuget does is provide a convenient way to install a program or library and manage its dependencies. The program must already contain its own architecture and sensible design structure before you apply a package manager to it.

In our shop's case, using NuGet for our internal projects only complicated the build process and made things worse. Consequently, I believe that the use of NuGet should be confined to its intended purpose, which is distribution.

  • I agree that package manager is not an architectural solution. But how can I proof to this stubborn idiot?! I have used internally created NuGet packages before without any issues, they knew it and that's why I'm there, but that was for a very well designed with fully modularized system. I don't know how to show them the issue! Thoughts?
    – Fred Jand
    Commented Nov 5, 2016 at 0:50
  • 1
    It comes down to good architecture. I've used internal NuGet packages with internal dependencies six layers deep. It's a nightmare. I've also used internal packages with no internal dependencies that are meant to be consumed at the top-most layer. If you don't take the time to properly design a solution, you'll just be moving the spaghetti elsewhere--which may be valid if it's a first step toward in an evolutionary process.
    – mgw854
    Commented Nov 5, 2016 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.