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.

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
DrMistry
  • 431
  • 1
  • 4
  • 8
  • 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 02 '16 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 02 '16 at 14:40
  • 1
    That depends on a lot of factors. With one project per solution, is everything written in a monolithic manner without Separation of Concerns? If it is, then SoC and code reuse (same models being relevant in multiple places, shared methods for data retrieval) are **very** good reasons to "increase interdependence complexity". – krillgar Dec 02 '16 at 14:43
  • 2
    It's probably nonsense. They're either not used to working like that and resistant to change, or they don't want to because they know it will cause some technical debt issue to flare up. – GoatInTheMachine Dec 02 '16 at 15:04
  • 1
    Thanks for the responses folks, I'm about to update the question to address your points. – DrMistry Dec 02 '16 at 15:15
  • 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 02 '16 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 02 '16 at 15:56
  • See my edit as a respond to your edit. – Doc Brown Dec 02 '16 at 16:01
  • 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 02 '16 at 18:35
  • 1
    I can see that having separate solutions per project can help to enforce good decoupling between projects - and I definitely think that once a project is used by multiple applications it should be **packaged and deployed separately to both** but assuming the project has been well constructed that abstraction can come later if/when needed. – Ant P Dec 03 '16 at 10:52
  • 1
    It sounds like they are organized as having 1 developer taking care of 1 project, and each developer has grown protective about his part of the system. This is not necessarily bad. If they allow others to mess with integration, new dependencies may be introduced outside their control. As fir building everything, you do not need a VS solution. You can have them deploy code to a build server and run your own MSBuild script. And, "helping to manage" is not exactly a role description that I as a developer would welcome without suspicion. – Martin Maat Dec 03 '16 at 12:28
  • insists on "good development patterns" but previously said "don't always send us the update source". Ever heard of version control and version control servers? – marstato Dec 12 '18 at 18:16
  • Try reading the question again @marstato – DrMistry Dec 13 '18 at 09:04
  • @DrMistry okay, sorry. I stopped reading at the good development patterns . – marstato Dec 13 '18 at 13:06

4 Answers4

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • 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 02 '16 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 06 '16 at 09: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.

KeithN
  • 149
  • 4
  • 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 04 '16 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!

Dominic Cerisano
  • 129
  • 4
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.

Kasper van den Berg
  • 2,636
  • 1
  • 16
  • 32