It was just mentioned that I&#39;m &quot;not exactly building the Sistine Chapel.&quot;  This is true, but I am building a freight management application, which isn&#39;t exactly as simple as drawing controls on a form (even though the vendors would have you believe it is).

I don&#39;t hold this against the person who said it, but I do feel the complexity of what I&#39;m doing is a little misunderstood, or that statement would not have been made.

Are there any good metaphors which might illustrate a project&#39;s complexity to non-programmers?

Are there any good metaphors for explaining project complexity to a non-programmer?

My firm just got its first large-scale development project inquiry and I would like to use an Agile process. The client has a vision for the application but openly admits to having very few requirements and recognizes that we will have to charge by the hour. Because of this, I&#39;ve all but sold him on an Agile approach.

The problem is that he wants a figure to budget around. I&#39;ve read a number of articles that pretty much advocate against giving up an estimate because the client will budget for that number and even as requirements change, the number in their head and in the books doesn&#39;t.

I&#39;ve read there are a number of ways to factor in pricing in the contract, but almost all of them (save one) incorporate an up-front number. This just seems to violate the entire set of principles of Agile development.

So my question is, if you&#39;re an Agile shop, how do you manage to circumvent this Catch-22 of Agile development?

Giving estimates for large scale projects in an Agile Environment

I&#39;m working in research and my bioinformatics work group needs a project management software for keeping track of multiple projects (Linux environment). Originally, we planned for using TRAC but then I got aware of REDMINE. Moreover, I read in some earlier posts from 2008 and 2009 that many projects had switched to Redmine. Right now, I cannot find any up-to-date or reliable comparison between both systems and thus cannot wage which one is better (maybe both are equally good).

**My question:**

Does anyone of you have **recent** experience in one or even both of these systems and can point out some (big) advantages/disadavantages of either Redmine or Trac (or even both)?

**Requirements would be:**

- svn and/or dcvs (Git) support
- document management
- ticketing
- bug tracking
- wiki / internal blog (i.e., knowledge management)
- multiple project support
- installation should be as easy as possible
- there shouldn&#39;t be hundreds of plugins to be installed before getting a usable project management software up and running (base installation should have most features)


Thanks a lot for your time!
Cheers

Trac vs. Redmine

I have a project that is open sourced using `git` for revision control. Soon, I am going to release a premium hosted version of the project as well, but there will be changes made to the code specifically for the premium hosted version (performance, etc.), that should not exist in the open source version.

I want to avoid having two separate directories/projects, because if I fix a bug in the open source version, that bug is most likely in the premium hosted version as well. I don&#39;t want to make changes in two places.

What is the best way to manage this? Simply branching in `git` won&#39;t work right, because some files need to have 2 versions: an open source version and a premium hosted version.


How to manage multiple versions of a project?

I would like to be able to duplicate an entire Xcode project, rename the project and the associated files without Xcode going mental, and without having to manually re-import all files to the project.

Duplicate and rename Xcode project &amp; associated folders

Under what circumstances - if any - does adding programmers to a team actually speed development of an already late project?



I need this baby in a month - send me nine women!

What are the best practices and rules-of-thumb to follow while maintaining code?  Is it good practice to have only the production ready code in the development branch, or should untested latest code be available in the development branch?

How do you guys maintain your development code and production code?

Edit - Supplementary question - Does your development team follow &quot;commit-as-soon-as-possible-and-often-even-if-the-code-contains-minor-bugs-or-is-incomplete&quot; protocol or &quot;commit-ONLY-perfect-code&quot; protocol while committing code to DEVELOPMENT branch? 

How do you maintain development code and production code?

(EDIT: This question is now outdated for my particular issue, as Google Code supports git now and I&#39;ve converted Protocol Buffers to Mercurial anyway. However, it&#39;s still of general interest, IMO.)

My [C# Protocol Buffers Port][1] uses github for its source control, and I&#39;m beginning to really enjoy using git. However, as far as I can tell, github doesn&#39;t provide any project management tools: defect and feature tracking, discussions, feature requests, docs etc. Given my affiliations, [Google Code][4] would be a natural choice, but it would seem odd to create a project there but host the source on github.

[This question about Fogbugz/Assembla][2] seems to mostly focus on the defect tracking. I was wondering what experiences others have had when it comes to a more &quot;complete&quot; project management solution. Does Fogbugz actually do everything I need? (Using a wiki for docs has its advantages, although I also want to be able to distribute documentation with the code.) Beyond the explicit features mentioned in the first paragraph, are there other project aspects I *should* be considering which I may have missed?

This will definitely stay an open source project, and although I&#39;d rather not pay I don&#39;t mind if a small fee is required. Currently I&#39;m the only developer, but that may change and there may very well be lots of people filing bugs and feature requests. (In other words, I  hope and expect it to be popular, but with me doing most of the work.)

Previously I&#39;ve *contributed* to various open source projects, but haven&#39;t done much in the way of running a very visible and active one. ([MiscUtil][3] is currently still &quot;hosted&quot; on my website, with occasional releases - the actual source control is on my local NAS.)

Anyone care to share their experiences?

EDIT: Another option I&#39;m now considering is a Google Code project (I really would like to be loyal to my employer) and an occasional merge from git to svn (at the very least, every time I do a release). This would allow non-git users to get hold of the source easily too.

  [1]: http://github.com/jskeet/dotnet-protobufs/tree/master
  [2]: https://stackoverflow.com/questions/39186/should-i-use-githubfogbugz-or-assembla
  [3]: http://pobox.com/~skeet/csharp/miscutil
  [4]: http://code.google.com

Project management to go with GitHub

I&#39;m fairly well read in the benefits and processes of Scrum. I get the ideas on the backlog, burndown charts, iterations, using user stories, and other various concepts of the Scrum &quot;framework&quot;.

With that said... I work for a web development firm that manages multiple projects at one time, with six team members that make up the &quot;production team&quot;. 

How does Scrum work with having multiple projects? Do you still just schedule an iteration for a single project in a certain amount of time and the entire team works on it, and then you move on to the next project with a new iteration when that iteration is completed? Or is there an &quot;agile&quot; way in managing multiple projects with their own iterations with only one team at the same time?

How does Scrum work when you have multiple projects?

What tips and &quot;standards&quot; do you use in your Redmine project management process?

Do you have a standard wiki insert template you could share or a standard way to work a project using bugs features tasks and support issues?

Do you let issues and updates get emailed into Redmine? 
Do you use the forums?
Do you use SVN repository?
Do you use Mylyn in eclipse to work the task lists?

I&#39;m trying to drag our dept. into some web based PM instead of emailed Word docs of vague requirements followed by Word docs explaining how to QA and Deploy that all get lost in a pile of competing updates and projects so that by the time I have to fix something, no one can find any documentation on how it works.







Redmine best practices

I have little more than beginner-level C skills and would like to know if there are any de facto &quot;standards&quot; to structure a somewhat complex application in C. Even GUI based ones.

I have been always using the OO paradigm in Java and PHP and now that I want to learn C I&#39;m afraid that I might structure my applications in the wrong way. I&#39;m at a loss on which guidelines to follow to have modularity, decoupling and dryness with a procedural language.

Do you have any readings to suggest? I couldn&#39;t find any application framework for C, even if I don&#39;t use frameworks I&#39;ve always found nice ideas by browsing their code.

How should I structure complex projects in C?

If so why? How much? 

I tend to inflate mine a little because I can be overly optimistic.

Do you inflate your estimated project completion dates?

This questions concerns mostly Unix/Linux style C++ development. I see that many C++ *libraries* store their header files in a &quot;include&quot; folder and source files in an &quot;src&quot; folder. For the sake of conformance I adopted this in my own code. But it is not clear to me whether this should be done for *application* code as well. I&#39;ve seen a few cases where a flat directory structure is used for that. What would be the recommended approach?



Separate &quot;include&quot; and &quot;src&quot; folders for application-level code?

So basically I am looking for good templates for writing both technical and functional specs on a project or work request.

What do you use? How deep do you get while writing the specs? Any additional general tips you could provide would be appreciated.

My company needs these badly. I work for a contractor and right now we do not use these documents at all. 

**EDIT:** I have read Joel&#39;s take about [Painless Specification][1], I really liked it, but are there any other opinions :) 


  [1]: http://www.joelonsoftware.com/articles/fog0000000036.html

Templates of Technical and Functional Specs

Currently, I&#39;m moving from a legacy version control system and moving my group&#39;s project to mercurial.  As one example of the kinds of code I&#39;m moving, I have a 25+ project Visual Studio solution, containing several separate application areas that all depend on common code.  Looking over Stack Overflow, the closest question I found was [this one](https://stackoverflow.com/questions/647462/best-way-to-organize-dependant-projects), but it merely mentioned version control.  I&#39;m looking for a bit further advice, on specific implementation techniques of using Mercurial to manage these dependencies.

A simplified view of the dependencies look something like the following.  (This is for illustration and example only; the actual dependencies are significantly more complex but similar in nature.)

                         Common Lib 1
                        /      |      \
                    ----       |       -----   
                   /           |        \   \
                App 1    Common Lib 2    \ App 2
                           /   |   \      \
                    -------    |    ------ |
                   /           |          \|
                 App 3       App 4      App 5

The Common Lib modules would be shared code - this would be a DLL or SO or some other library that would be used between all the apps simultaneously - both at compile and run time.  Applications would otherwise be able to run independently from each other.

I have a couple goals with setting up my mercurial repositories:

* Give each significant application or component group its own repository.
* Make each repository self contained.
* Make the sum total of the project self contained.
* Make it easy to build the entire codebase at once.  (eventually, all these programs and libraries end up in a single installer.)
* Keep it simple.

One other point is that I have a server set up where I have separate repositories for each of these projects.

I see a couple ways of laying these projects out.

# 1. Create a &quot;Shell&quot; repository that contains everything.  

This would use url-based subrepos (eg, in the .hgsub, I&#39;d do something like &lt;code&gt;App1 = https://my.server/repo/app1&lt;/code&gt;.)  Laid out, it would look like the following:

    +---------------------------+
    | Main Repository           |
    | | +---------------------+ |
    | +-| Build               | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| Common Lib 1        | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| Common Lib 2        | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| App 1               | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| App 2               | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| App 3               | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| App 4               | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| App 5               | |
    |   +---------------------+ |
    +---------------------------+

Each main folder in the shell repository would contain a subrepo, one for each project area.  Dependencies would be relative: Eg, since App 4 needs Common Lib 2, it would simply use relative paths to reference that common library.

Pros of this approach:

* Each library is pulled down once and only once.
* Mercurial&#39;s subreos will ensure that the same version of the library is used across all project automatically, since only one version of that subrepo exists in the project.
* It&#39;s easy to find each resource.

Cons of this approach:

* I can&#39;t work on an App independently.  Eg, if I work on App 2, and it needs a change to the common libraries, all of the other apps will have to take those changes right now.
* If I pull an App repo by itself, I have to figure out (or know) what other dependent repos it requires by hand if I want to build it.
* Dependencies are not strongly separated - it would be tempting to insert a new feature  anywhere since it was easy to get at all the features.

# 2. Have dependent subrepos be wholly contained.

In this approach, each application would have its own repository (as before) but this time also contain subrepositories: one for its own source, and one for each dependent subrepository.  An overall repository would then contain each of these project repositories, and know how to build the entire solution.  This would look like the following:

    +-----------------------------------------------------------------------+
    | Main Repository                                                       |
    | +--------------------+ +--------------------+ +--------------------+  |
    | | Build              | | Common Lib 1       | | Common Lib 2       |  |
    | +--------------------+ | | +--------------+ | | | +--------------+ |  |
    |                        | +-| Lib 1 Source | | | +-| Common Lib 1 | |  |
    |                        |   +--------------+ | | | +--------------+ |  |
    |                        |                    | | | +--------------+ |  |
    |                        |                    | | +-| Lib 2 Source | |  |
    |                        |                    | |   +--------------+ |  |
    |                        +--------------------+ +--------------------+  |
    | +--------------------+ +--------------------+ +---------------------+ |
    | | App 1              | | App 2              | |  App 3              | |
    | | | +--------------+ | | | +--------------+ | |  | +--------------+ | |
    | | +-| Common Lib 1 | | | +-| Common Lib 1 | | |  +-| Common Lib 2 | | |
    | | | +--------------+ | | | +--------------+ | |  | +--------------+ | |
    | | | +--------------+ | | | +--------------+ | |  | +--------------+ | |
    | | +-| App 1 Source | | | +-| App 2 Source | | |  +-| App 3 Source | | |
    | |   +--------------+ | |   +--------------+ | |    +--------------+ | |
    | +--------------------+ +--------------------+ +---------------------+ |
    | +--------------------+ +--------------------+                         |
    | | App 4              | | App 5              |                         |
    | | | +--------------+ | | | +--------------+ |                         |
    | | +-| Common Lib 2 | | | +-| Common Lib 1 | |                         |
    | | | +--------------+ | | | +--------------+ |                         |
    | | | +--------------+ | | | +--------------+ |                         |
    | | +-| App 4 Source | | | +-| Common Lib 2 | |                         |
    | |   +--------------+ | | | +--------------+ |                         |
    | +--------------------+ + | +--------------+ |                         |
    |                        | +-| App 5 Source | |                         |
    |                        |   +--------------+ |                         |
    |                        +--------------------+                         |
    +-----------------------------------------------------------------------+



Pros:

* Each application can be built by itself, independent of each other.
* Dependent versions of libraries can be tracked per-app, instead of globally.  It takes an explicit act of inserting a subrepo into the project to add a new dependency.

Cons:

* When doing the final build, each app might be using a different version of a shared library.  (might need to write tools to sync the common lib subrepos.  Eww.)
* If I want to build the entire source, I end up pulling down shared libraries multiple times.  In the case of Common Lib 1, I would have to pull it eight (!) times.

# 3.  Don&#39;t include dependencies at all as subrepos - bring them in as part of the build.

This approach would look much like approach 1, except the common libraries would only be pulled as part of the build.  Each app would know what repos it needed, and put them in the common location.

Pros:

* Each app could build by itself.
* Common libraries would only need to be pulled once.

Cons:

* We&#39;d have to keep track of versions of libraries currently used by each app.  This duplicates subrepo features.
* We&#39;d have to build an infrastructure to support this, which means more stuff going into build scripts.  Ugh.

# 4.  What else?

Is there another way of handling it?  A better way?  What ways have you tried and succeeded, what ways have you tried but hated?  I&#39;m currently leaning towards 1, but the lack of application independence, when it should be able to, really bothers me.  Is there a way to get the nice separation of method 2 without the massive duplicate code pull and dependency maintenance nightmare, while not having to write scripts to handle it (like in option 3)?

What&#39;s a good way to organize projects with shared dependencies in Mercurial?

I&#39;m working with my brother on a website idea we have, and we&#39;d like to use a tool to plan sprints and assign estimates to individual tickets.

Atlassian&#39;s JIRA+Greenhopper looks fantastic but costs $20/month and at this stage we&#39;re just validating our idea and would rather not spend money on a tool if we can avoid it.

Are there any free alternatives to these tools?

All Project Management Solutions on Gang of Coders

Total of 16 Project Management Solutions