True story: a team building a system.  They decide that one chunk of code might be valuable in another project or two.  So they extract it into a library and open source it.

Project complete, team reorganizes and begins a couple new projects.  Both new projects depend on that library.  For awhile everything is great.

Sooner or later someone needs to make a change.  It’s sort of a pain, because the source code is in another IDE configuration.  Actually it’s been awhile since anyone worked on it and it’s hard to find a developer on the team who has that version of the IDE installed.  But the change happens, painful as it may be, because it has to.

Someone later gets lazy.  They build it locally and copy the assemblies directly into the lib folder.  Now the library was compiled from source code that’s not in the version control system.  This is spinning out of control.  Or maybe that was intentional – because the other team is using the library too, but they have different needs and we’ve sort of been in a mutually-assured-destruction paralysis about what changes to make.

Eventually someone realizes the solution is not to depend on this library, the compiled bits, but to just copy the source code over.  We need to make our tweaks, they need to make their tweaks.  It makes sense.   So we lose our code reuse; does anyone care? 

This dirty-feeling code copying can be a good idea for a non-technical reason:  it emphasizes that the important element of reuse is the human expertise to understand, create, use and modify a solution that solves a particular problem.

Turns out NuGet is great for this.  I noticed that Rob Conery packaged his Massive library as just a file.  A source code file.  Not a .dll.  Great idea, and I immediately thought of all the code that I want to share among many projects but also have the flexibility to change, now – without context switching or fear of repercussions.

You just put the files in a Content subdirectory and the NuGet process will shove them in the project root or App_Code or wherever.

I did the same with a little utility class that we use a lot, and I’m going to do it some more. 

For many teams, a hosted NuGet feed with content files is the new helper library.

I had it on a pedestal – shining, holy, even – a easy, breezy process in which things happened with little effort.  Maybe I was confusing “idealism” from the reality of “ideal”. I guess I’m discovering what practitioners have known forever: Agile is anything but laissez faire.  It requires serious mental discipline.  The discipline and transparency involved is, to put it bluntly: more work.  This is a good thing. 

More work doesn’t mean more difficult work, more ineffective work, more spinning of wheels – it means more tasks complete, less "play time", and a more satisfying "leaving work experience".  Just don’t let all that hard work surprise you.