System design question

Hope this is in the correct place to post this question!

The company I work for does project work which is geographically dispersed. Each project lasts for a lengthy time and operates semi-autonomously from the rest of the company.

There has been a call to standardise the software used on these projects. As you can imagine in such a set up there has been a lot of "I prefer X over Y" and therefore we;ll use it. So each project often ends up re-inventing the wheel.

The two main competing ideas for allowing a standardisation of the software are as follows:

1) Have a system written in one language tied to one database type (For eg VB.Net and some flavour of SQL) This source code is then taken from project to project and the code is changed to meet the individual needs of the project. The "best parts" of this code is kept to be incorporated into the next project.

2) Have a system in which all forms are compiled individually into DLL's. These are then accessed by a main menu. The idea behind this is that any software development done for a project could be done in the language/database most convenient to the on-site developper. Once again the "best" parts of the system would be exported to the next project.

Any input from the forum as to the best way to go would really be appreciated.

We are not a software company and this system will be for internal use only.

Thanks for any input

If you are planing on forking the original project to multiple different (yet similar) version, make sure you work out the source control first. There are a lot of revision/source control systems out there, like Team Foundation Server from MS, or Apache Subversion. That way you can track the parts of the source that are shared and only have to implement changes/fixes at one point to update all versions of the software.

Thread moved to 'General Developer' forum.

Thanks Baja

Source control is pretty much taken care of (fortunatly)

What we;re trying to figure out is the way forward in terms of how to set up the systems architecture for projects going forward.

As I said we;re not a software company and there are a huge amount of unknows out there for us. We are really thin on the ground when it comes to competent developers. So much so that both options seem good and bad at the same time!

We would just hate to get stuck with some weird technical problems down the line and not have the correct manpower resources available to fix the problem.

Sounds like where I work... and the way we handle it: Standardize. One app for everyone. Don't make changes for the whims of a single project. Training.

We're not a software house either, all development is for internal use only. To use the apps, the site has to login to the network (via VPN & the internet, if the case is extreme, then sat coms are used too)... go to the intranet home page, click the app. It is then deployed using ClickOnce. Our enterprise is a hybrid of about 20 systems that integrate and talk to each other. Some are web apps, others are actual winform apps.

-tg

Regardless of the exact method you choose to proceed, I'd advise to go for a minimal framework initially. This should be kept to an absolute minimum that can be useful to the next project that you undertake. See how it goes, real-world experience is invaluable. Decide what works and what does not work. Try to generalize and introduce configuration as needed. After two or three iterations of this you may have a usable framework.

The thing with trying to introduce standardization in teams that are dispersed and not in tight communication with each other is that there may be resistance. You'll need a lot of discipline and internal training in order for this to work.