Systems and sub-systems

I've worked on numerous systems, but none with sub-system packaging, why not? I must have worked for the wrong companies....

I've worked on projects that package layers into DLLs, e.g. there was a "data access" DLL, a "business layer" DLL, and usually the UI is a single EXE. This type of system is easy to develop, but any change (e.g. adding a feature that spans UI, business and data layers) requires you to re-test and re-release the whole system.

I recently worked on a large finance system that had gone too far the other way. Each UI feature was packaged into it's own DLL, with it's own business layer, and data layer. Sounds ideal, right? Wrong. I was working with two Visual Studio solutions, one for the back-end services, one for the UI, with each solution having over 100 projects in. It took up to ten minutes to load the solution, and ten minutes to run-it-up in Visual Studio.

You might ask if I needed all the 200 projects - I didn't - but someone had created nasty inter-project dependencies. For example, all error messages were stored in a single file which all projects depended on. So adding an error message caused all project to require re-compilation. There was also some "common" UI elements that had been grouped into a project, but this common project referenced (directly and indirectly) over 30 other projects.

So what ever happened to sub-systems? Grouping related things into sub-systems (projects), that have limited external interfaces, is the best of both worlds. You can change a part of the system without having to re-test and re-deploy the whole thing, and you don't end up with spaghetti projects that are slow to work with.