3

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?

11

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:

  1. Contractor working on Solution A modifies common code and commits.
  2. The Continuous Integration Server spins up a build for all affected solutions and runs their automated tests.
  3. Solution B fails to build.
  4. Solution C builds fine but has its automated tests fail
  5. 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
  • Thanks, unfortunately there aren't many automated tests. I joined three months ago and wrote the first one! Implementing these backwardly isn't really feasible here, only for new projects. – Jay Jul 22 '16 at 6:42
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:

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
  • 1
    Packaging doesn't solve the problem of your contractor breaking your stuff, you just don't know about it until someone revs the nuget/bower/gem version (so then people don't do it). – Telastyn Jul 19 '16 at 16:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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