Currently we have about 20 solutions. The majority of these have multiple projects, including share utils projects, data access, etc. We’ve had a few problems where a contractor changed something in a common project and unknowingly this breaks a number of other solutions. We currently have 7 perm developers and 3 long term contractors, soon to be increasing to around 10.
We’re currently trying to decide a new software architecture in our company. Currently we’re trying to decide whether we should combine our solutions into a single super solution, or have lots of smaller solutions with some common bits as one solution and a common.dll, etc (my preference).
As I see it the pro’s and con’s are as follows:
Super Solution:
Pro’s
-
One solution means that if a common project is broken it won’t
compile, so you won’t accidentally break another project. -
Would increase the possibility of code reuse, possibly decreasing
development time. -
Some application have a massive overlap, take different web apps in
an intranet for example.
Con’s
-
Possible added complexity of deployment.
-
If one application (A) is changed, the changed bit may be tested. If something was changed that effected another application (B) but this wasn’t deployed, next time (B) is changed and deployed the previous changes would be pushed out and this could be in an area that wasn’t going to be extensively tested.
-
The solution would be huge, possibly making it more complex and harder to maintain, especially if it was a fairly stand alone simple application.
Multiple Solutions
Pro’s
-
Simple applications will have simple solutions that should be very easy to maintain.
-
Easier deployment.
-
Easier testing.
-
If common area’s are referenced DLL’s there is less chance that a change will break another application.
Con’s
-
Discourages code reuse.
-
If common area’s are added as projects it will make it difficult to know if a change has broken another application.
-
If common area’s are DLL’s, changing these would be another step.
-
Some applications ‘belong’ together in one solution, how to determine which should be grouped and which shouldn’t be?
Can I ask what other people here do?
Should the common area’s be added as projects or as DLL’s?
Anything else to consider?
We’ve had a few problems where a contractor changed something in a common project and unknowingly this breaks a number of other solutions
That’s is unfortunate
We’re currently trying to decide a new software architecture in our company
STOP.
You have a process problem, not an architecture problem.
A much simpler, and more valuable, fix to this would be to implement Continuous Integration and Automated Tests.
It’s not perfect, but you would learn very quickly if a change in a common project broke other solutions. For example:
- Contractor working on Solution A modifies common code and commits.
- The Continuous Integration Server spins up a build for all affected solutions and runs their automated tests.
- Solution B fails to build.
- Solution C builds fine but has its automated tests fail
- CI Server sends developers an email alerting them to the problem.
Granted, this isn’t as good as being notified at compile time, but getting a notification minutes after your commit is pretty darn good.
1
To put all the applications in one solution is to say that all of the applications are related somehow. If they aren’t, don’t put them in the same solution.
What you really are after is code-reuse. Since you don’t specify a technology stack I’ll list out some options in multiple technologies. These allow you to share code without stuffing applications together that functionally don’t belong:
- C#/.NET: Host your own NuGet feeds
- JavaScript: Bower
- Ruby: Gems
You get to create, package and properly version class libraries, and manage them as dependencies in your other projects, and you can create your own private company-specific repositories so you aren’t making proprietary code public. Now your solutions can remain focused on the solution, rather than the best way to reuse code.
So I guess my answer is C) neither of the things above.
1