That is one of the wonderful things about haskell, most languages have a negative correlation between codesize and productivity, however with haskell there is a strong positive correlation. You can re-use so much that as your code base grows it becomes easier to add new features rather than harder. I solve that problem by having a darcs repository for all my utility modules, then when I want to use them in a project, I just 'darcs pull' them into the current repository and they appear. as long as a patch doesn't cross the boundry between the utility modules and the rest of the codebase I can push changes upstream to the utility repository from my specific project, or pull in new improvements to the utility functions. I can also make local modifications to the utility modules and just not push the local modifications upstream if needed. The cool thing is that the darcs history has the merged history of my projects, and tagging with a version number or release will snapshot both your program and the exact version of the utility routines used at that time. The ability to have multiple "sibling" darcs repositories is a really powerful feature. quite handy. I had a similar system before darcs where I used a shared RCS directory between projects, but that wasn't nearly as seamless or integrated. Plus it makes it easier when collaborating, as far as anyone is concerned, the project is a single darcs repository they can get and build and create patches for. The fact that behind the scenes it is actually a collection of repositories spawning patches. modifying them, and exchanging them in a bizarre parody of bacterial plasmid exchange* is completely transparent. John * stolen prose, I just liked the sound of it.