28

I'm helping to manage an external team who are starting to develop new versions of some existing products. Historically, this team has always used a model of a single project in a single solution for about 30 modules in Visual Studio which go together to produce a deployable build.

This is having a detrimental impact on build reliability and quality, because they don't always send us the most up-to-date source code. We're trying to press them to unify all referenced code in to a single solution, but we're getting some resistance - specifically they keep talking about interdependence between modules (read "projects" in Visual Studio) being increased if everything is placed in a single solution file. None of the code in the separate solutions is used elsewhere.

I insist this is nonsense and good development patterns will avoid any such problem.

The team in question also perform bugfix and new feature development on an existing product, the experience of which has been fraught to say the least and suffers from exactly the same problem of splitting over multiple solutions. We've been refused access to their source control (TFS), and the approach we're taking to unify the codebase is to try and at least reduce the number of missing updates and more than occasional regressions (yes, fixed bugs are getting re-introduced in to the product) by saying "send us a ZIP of the entire solution folder so we can unzip, open it in Visual Studio, and press F5 for testing". In terms of general structure and quality, the code is pretty poor and hard to support. This experience is why I'm intent on getting the working processes right as early in the development cycle as possible.

Is there something I'm missing? Is there ever a good reason to keep all that code separated out? For my money it would have to be so compelling a reason that it would be common knowledge, but I'm more than willing to concede that I don't know everything.

Improve this question
14
  • 6
    If the team is external, it'll be hard to try to change anything. Instead of focusing on the problem you're trying to push your idea. The problem is "they don't always send us up to date code", have they resolve this issue, in the way they prefer. Can't they grant you access to version control system?
    – RMalke
    Dec 2, 2016 at 14:38
  • 9
    It sounds like nonsense. The projects will be no more and no less dependent on each other whether in one or thirty solutions. The reason for keeping code in separate solutions is because the resultant library is used by multiple, separate deployable builds. This doesn't sound like the case for you.
    – David Arno
    Dec 2, 2016 at 14:40
  • 3
    It sounds like you have a lot of non-technical problems that are best solved by changes to your contract and statements of work.
    – Ross Patterson
    Dec 2, 2016 at 15:26
  • 10
    Creating a single solution doesn't necessarily mean they have to give up the individual solutions, as a project can exist in more than one solution.
    – Erik Eidt
    Dec 2, 2016 at 15:56
  • 6
    I'm not sure why you are wondering about technical solutions to something which is essentially a people problem. Fire these people, and hire people who are above mediocre level of competence. That means you'll pay more, but its definitely worth it in I.T. in terms of reduced total cost of ownership. The longer you hold on the more you will suffer.
    – Bradley Thomas
    Dec 2, 2016 at 18:35

4 Answers 4

Reset to default
58

You don't need to tell them how to structure their projects. Instead, make it a hard requirement that you can build the system from source by running one single script, without getting any errors. If that scripts runs Visual Studio or Msbuild or some other tools, and if those are called once, 50 or 100 times should not matter.

That way, you get the same "test for completeness" of the code as you would get by putting everything into a single solution. Of course, that script does not tell you if the team has really checked out the latest version from their source control, but having the whole code in one solution would not check that, either.

As a reply to "interdependence between modules being increased if everything is placed in a single solution file" - this is proveable nonsense, since adding projects to a solution does not change any of the dependencies between projects, the dependencies are a result from one project file referencing another, which is completely independent from which solution references which project file. No one stops that team to have both - a single solution which references all projects, and also individual solutions each one referencing only one project.

Nevertheless I would suggest to add a build script. This has benefits even when there is only one solution file. For example, it allows one to run a VS build with a preferred configuration, let you copy the final files for deployment (and nothing more) to a "deploy" folder, and may run some other tools and steps to make the build complete. See also F5 is not a build process!, and The Joel Test.

Improve this answer
2
  • Yes I agree that F5 is not a build process, but we want to test their code within the dev team before passing out to our QA process for end-to-end testing, because of the regressions and update failures. As I've said, we don't have access to their TFS so we have to import their changes in to our own codebase, and then check it in to TFS. Right now this process is so poor that running autobuild on checkin is a total waste of time! We have autobuild on the rest of our product estate and it works very nicely indeed for us.
    – DrMistry
    Dec 2, 2016 at 16:24
  • Just wanted to add, that "The Joel Test" stuff is excellent and I'd recommend having a good look. Thanks very much!
    – DrMistry
    Dec 6, 2016 at 9:55
4

It would depend on how much the compiled assemblies are re-used. If there is no re-use of assemblies, then there is no real reason to keep the "modules" separate. In-fact in my experience this is more of a hindrance.

In the development team I am a part of we have independent libraries we have written that are used in multiple products as a separate solution, which in this case it makes sense otherwise we would have to compile Application A to keep Application B up to date, which might be required to keep Application C up to date.

Each product is kept in its own solution, even if there are multiple projects making up the product. This way we only have to build the Library solution to keep its shared code up to date in all developed products.

Improve this answer
1
  • None of the split-out projects are used anywhere else at all, that's the frustrating thing. They're all used in this one single product and nowhere else!
    – DrMistry
    Dec 4, 2016 at 17:06
2

Every software company I ever worked for had a core development team that provided the head branch covering the foundational use cases of the company's products.

Branch developers that use the core repository are responsible for discovering improvements and submitting pull requests to the head branch for review. This is usually how one becomes a core developer, by showing one can make better contributions than just fanning the flames of an architectural conflict.

It is likely your company simply does not have the resources to immediately "unify all referenced code a single solution". Suggesting they do so without understanding their budgetary constraints is (at the very least) likely to prevent one from becoming a core engineer.

So formulate your grand vision into a few devastating pull requests to the core, and prepare to defend thyself in review!

Improve this answer
1

There is a kernel of truth in the assertion "Using a single solution for multiple projects increases interdependence complexity".

A single solution make referencing a project from an other project (i.e. reusing code of a project a.k.a. "introducing interdependency complexity") easier:

  • instead of browsing your entire filesystem/global assembly cache for the referenced assembly, you can select the project from a limited set of relevant projects in the solution; and,
  • when reading source code it is much more easier to jump to a referenced project in the solution than to an arbitrary (binary) assembly.

So in the hands of an undisciplined team using multiple projects in a single solution can lead to lots of carelessly introduced dependencies. However, a team can better try to learn the necessary discipline to carefully manage the dependencies and then use the ease of reuse that using solutions offer.

Improve this answer

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