Good afternoon

I would like to know how do you guys organize your project folders?

I had once a boss that suggest me to organize by Customers.

|----Customer 1
     |---- A Cool Solution 1
           |---- source
                 |---- version1.0
                 |---- version1.1
           |---- docs
                 |---- analysis
                 |---- meetings
                 |---- manuals
|----Customer 2
|----Customer 3

A friend of mine told me to organize tem by Technology

     |---- C#
          |---- Customer 1     
                |---- A Cool Solution 1
                      |---- source
                            |---- version1.0
                            |---- version1.1
                      |---- docs
                            |---- analysis
                            |---- meetings
                            |---- manuals

And you? Do you have a clever way to organize your project folders?


This is what we've been using:

|----Customer A
     |---- Project 1
     |     |---- BuildControl       (CI/nAnt/Make/MSBuild files and config, etc)
     |     |---- Documentation      (In XML format so we can 'build' them)
     |     |---- Source
     |     |     |---- Component X
     |     |     |---- Component X.tests
     |     |     |---- Component Y 
     |     |     |---- Component Y.tests
     |     |---- Testing
     |     Project 1.sln      (Has folders as per project on-disk structure)
     |---- Project 2
     |---- Shared/Common components
|----Customer B
|----Customer C
|----<Our Company>
     |---- Internal Project A
     |---- Internal Library B

We've been using this structure for multiple projects with many different customers for years now and it works very well.

It's very similar to your initial suggestion, but we use version control to manage the versioning. The server repositories are named as "Customer X - Project Y", rather than anything else. This allows us to have external contractors working on some projects but not able to access others as we can set permissions at the version control root.

Everyone checks out their working copies to wherever they want on their (Windows) dev machine and uses the SUBST command to map a drive letter to that location. That way we can have hard-coded relative paths in build files, etc, that work across everyones' setup. So, for example, we can have links to shared libraries, if we so wish. We usually use version control links/aliases to achieve this tho.

One big benefit of this structure is that you can isolate customers' code from each other. This is useful if you need to (a) send them regular updates of the source for integration purposes, (b) have external contractors working on selected parts of the code.

Your second suggestion won't work so well with a complex project which uses more than one technology.

| improve this answer | |
  • Pretty reasonable, but -1 for requiring hardcoded absolute paths. Hardcoded relative paths should work for 99.9% of things. – Wyatt Barnett Jan 4 '12 at 20:45
  • 1
    Er, did I put absolute paths in there? – JBRWilkinson Jan 5 '12 at 22:30

I'm pretty flat:


Some varation getting there depending on box, but behind that there are just lots of individual folders for projects. Real deal lives in source control anyhow, so this is just the temporary local home.

| improve this answer | |

I have a structure that loosely looks like the following:

|-- Developer/
|   |-- Projects/
|   |   |-- Archives/
|   |   |-- Current/
|   |   |-- Work/
|-- Projects -> ~/Developer/Projects/Current

Archives contains old projects I'm no longer working on. Work contains work-related projects. Current is all current development. Then, in my home directory, I symlink Projects to ~/Developer/Projects/Current. ~/Projects also includes symlinks to some work projects.

| improve this answer | |
  • Moving projects from Current to Work to Archive don't go well with using source version control tools. In this case it's better to have folder references/link (outside of working copy). Maybe you are moving working copies inside 'archives', 'current' and 'work'? – Fil Jul 21 '17 at 15:14
  • 1
    @Fil: I use Git. Each project is its own self-contained repo, so it doesn't matter where it gets moved to. – mipadi Jul 21 '17 at 21:04

I also have a flat structure.


Agreeing with Wyatt Barnett, real deal lives in source control anyway.

Just want to add that there shouldn't be anything special about folder structure anyway, since many IDEs provide shortcuts to recent projects/files anyway. And how many projects does anyone work on anyway? Truly, only by definition, the recent ones.

Also, I only add recent projects into top level folder anyway. I archive all the older and completed stuff into:


or something like that. I archive what I generally won't be working on again.

| improve this answer | |
  • You'd be surprised -- I typically need a dozen or so projects hooked up, current and ready to run on my "go" laptop and can easily open a half dozen in the course of a normal day. – Wyatt Barnett Oct 26 '10 at 12:19

I have, in the past, used Subversion repositories to store my source documents, and followed the "project-minor" convention for repository organisation, which I have found to work very well for both large and small organisations.

We would structure our repository branches; tags & trunk as follows:

         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject

Within the actual source tree itself, we would use (something like) the following structure:

        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct-+
        |                               +-build
        |                               +-doc
        |                               +-test
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo

The idea was (and still is) to use the structure of the repository to help structure communication between the engineering team; the customer-facing part of the business and various other stakeholders & domain experts.

To wit: Source documents that sit in one of the "project" directories get used (and earn money) only once. Documents that sit in one of the "productLines" directories earn money as many times as a product from that particular line gets sold. Documents that sit in one of the "libraries" directories earn money as many times as any of the products that use them get sold.

It makes the notion of amortization of costs explicit, and helps build support for source document reuse across the business.

In an ideal world, the customer facing part of the business would also use this structure to store presentations & other sales collateral, so developers can see what customer expectations have been created, right alongside the relevant product directory, and customer facing colleagues can track development progress on the features and products that they are selling.

It also means that there is a common structure over which our build automation tools can operate. (Our build scripts walk the source tree looking for "build" folders within which they find configuration files specifying how each component is to be built; a similar process happens for documentation generation and testing). Again, in an ideal world, the organization's website and other marketing collateral could be built in the same way.

As one final note; the continuous integration system knows that it needs to trigger a build; static analysis; smoke test & unit test run each time trunk is modified, each time any "tag" branch is modified, and each time any "AUTOMATED" branch branch is modified. This way, individual developers can use the CI system with their personal branches, an important capability, IMHO.

| improve this answer | |

I think that you means "documentation folder". I organise my documents for sector first at all, after for customer/application, at the end for "developing and maintenance".

Example: Projects

  • Financial

    • Web application

      • App Alpha

         - source
         - functional docs
         - etc etc (testing, meeting with customer)
      • App Beta

         - functional docs
         - etc etc (testing, meeting with customer)
    • Desktop software
  • Energy & utilities
| improve this answer | |
  • What about version control? Doesn't an Alpha document become a Beta document as it progresses? – JBRWilkinson Oct 25 '10 at 21:55
  • In local desktop I haven't all the copies of all the version: I have got the last stable version of code, documents, etc. If I need of another previous version I download this version by Subversion et similia (storing as another project in the sector: App Beta_version_XYZ if financial) – alepuzio Oct 26 '10 at 13:42

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