As the architect for the whole system, I am responsible for making sure that when we connect all the pieces together, and they don’t work, we’ll be able to quickly find out why.

The fact that some of these pieces are developed at other companies doesn’t change that. Also, beyond affecting what interfaces those pieces expose/implement, I can’t dictate how those companies develop/build their pieces. I want to receive from those companies binary artifacts whose behavior I can verify (with unit tests, for instance).

Although I wish that I could positively affect those other companies’ build processes, its more important for me to focus on the team, or teams, in my company.

As to the issue of whether an interface being an element of development or integration – I think that its both, if done right.

Consider the case where 2 or more companies depend on a common package, like the one containing IEntity. Its really important for me to know that all the binaries provided by all companies were developed and tested against the same version of that shared package, otherwise there’s a good chance that things will break in unexpected ways (depending on the backwards and forwards compatibility characteristics of that package).

Of course, such a process may not scale down so well.

>> Not all source is necessarily in a single repository. <<

Well that’s probably your biggest problem. I would make a point of converging the source depots even if it means having a process that pulls stuff from other SCCSs nightly.

I disagree. That means lower stability because you cannot be sure what it is they’re running without looking at the version number of each and every DLL. The more unknowns there are, the less stable the system is. When you release everything from source control it is controlled – if you have a good build system it can dump out what has changed since the last build was performed (including the files) so you can be absolutely sure what it is they’re getting. I mean, if you don’t know what your build produces then what hope is there?

Like I said, it greatly depends on your setup and the nature of your development – but I can say that for at least 5 larger projects I’ve worked on, they were each in DLL hell until we made the decision to move towards holistic deployment.

John,

1. Not all source is necessarily in a single repository.
2. By having more granular deployment, and smaller iterations, a smaller percentage of your deployment footprint changes each time. That means higher stability.

Paul,

I shall consider myself fired. But, for those clients who haven’t fired me yet…

I’m not worried about the cases where programmers quickly home in on a bug, fix it, and move on. I’m worried about the bugs that don’t show up on the programmers machine, or sometimes do, and sometimes don’t. I’m worried about bugs that we thought we fixed 2 iterations ago, but have suddenly come back. These are the kinds of things that eat up project time, and don’t behave deterministically.

Mehran,

By following my “first principle of design”, I usually avoid the problems you describe. See:
http://udidahan.weblogs.us/archives/035032.html
http://udidahan.weblogs.us/archives/035222.html

Same applies if you want to minimise the number of files that need to be re-deployed in a patch release. But be careful. If your application has too many components, it is very likely that a bug fix needs many components to be re-deployed. Look at Windows service packs for instance; they include hundreds of updated files, which is defeating the purpose of minimising the number of re-deployed files and could end up in versioning conflicts too.

In terms of development, in the same way that having one large project (and therefore one assembly) can prove to be very slow, having too many projects with project references will have the same effect as the referenced projects need to be recompiled and the references in parent projects need to be updated, and this process can be repeated many times, based on the depth of project reference tree.

As you mentioned, it is up to the solution architect to decide which way to do based on project environment and complexity.

Also if you were on my project and randomly downed-tools to grandstand in front of the whole team then I’d fire you. There’s no room for prima donna programmers of development teams in my opinion.

And your grandstanding adds-up too does it not?

One Prima Donna Coder = 3 Months Gone

>> From that version number, we can find all the specific version numbers of the DLLs that comprise that system wide version number. <<

But why. From a version number you can go to source control and see what changed between labels. What does this have to do with DLLs? The only source they have to look through will be a diff report between those two version labels.

I think there are very few reasons to separate /components/ into their own DLLs, let alone individual interfaces. In my mind DLLs are a necessary evil – necessary only when sharing classes or interfaces between modules.

Surely you’ve heard the phrase ‘DLL hell?’ – it’s not limited to COM at all. It’s limited to anything that is deployed piecemeal. The more granular your deployment, the more room there is for errors caused by mismatched DLLs, or a botched compilation that linked against the wrong DLLs. In my experience it causes FAR more headaches than it’s worth. I’m 100% a proponent of deploying applications as an atomic entity. Even patches go out as the entire thing, just to ensure that somebody doesn’t apply a patch in the wrong order and mess everything up. You say it reduces the source code – but I don’t see it. A DLL means an extra project file, extra references list, extra using statements, the list goes on. And this isn’t to mention the performance hits of all those assembly resolutions. In my experience you can increase the size of the project by an order of magnitude by being DLL happy.

What we have found to be one of the biggest time savers, and therefore money savers for our customers, is the use of an agreed upon versioning system for our projects. This is a cross-cutting concern which involves our SCM, project dashboards, project structures, requirements tracking, and issue tracker. It comes down to having the right infrastructure in place to make getting work done much easier.

Now, most of the projects I work with are Java based but they have similar issues as described above. We use Maven 2 to build, test, deploy, and view project dashboard across these projects. We found this to be so helpful that we even created plugins (or Mojos as they put it) for our .NET projects. Reports for FxCop, NDepend, NUnit, and others all get placed into the Maven 2 dashboard. It can even build our solutions.

The consistency allows our developers to help across project lines without dealing with as much getting up to speed homework. It doesn’t eliminate it, but we are working on that.