Reuse is overrated, then came package management

Reuse is overrated

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.

About these ads
This entry was posted in Agile, Tools. Bookmark the permalink.

7 Responses to Reuse is overrated, then came package management

  1. Pingback: Dew Drop – Mile-High Edition – February 27, 2011 | Alvin Ashcraft's Morning Dew

  2. Jake Scott says:

    You could also put the code files on github :)

  3. Matt says:

    It’s on bitbucket. http://hg.headspringlabs.com/enumeration
    I get your drift though. I know teams keep their dotfiles in VCS and share them, and obviously entire libraries. The difference is I do not want changes to make thier way back. This is a one way, one time pull.

  4. dotnetchris says:

    So if you have the code files get copied in, what happens when you update the package?

    Chaos?

    • Matt says:

      Dogs and cats living together, yeah. The experience I’m going for is a one-time addition to the source, not the introduction of an updatable library. The point is to *not* reuse.

      • dotnetchris says:

        I read the article linked about reuse being overrated and I certainly don’t agree with the premise of it.

        I have worked at places that were described in the article that have the “god framework” that becomes THE point of contention and all chaos breaks loose. That’s not caused by code reuse, that’s caused by bad development, bad code and bad architects (most specifically this one).

        Writing code following SOLID practice along with a track record of enterprise development to use as a basis of knowing when code truly is important vs only important to this project I have found 0 issues with code reuse EXCEPT for package management.

        Prior to nuget, package management in .NET has been entirely a nightmare. The proverbial DLL hell. I had wanted to formally wrap our software development process around nuget for shared pieces at my shop however for a long time nuget didn’t work correctly on any of our machines (fixed as of a 1.2 build from their CI server) so thankfully soon I’ll be able to go back and address this and build nuggets for all of my share able code.

        The amount of DRY violations I’ll be able to solve by finally having an easily shareable extension method library will be beautiful. Especially since many projects will end up with similar but extensions that exist in other projects but weren’t easily discoverable since there’s no gem update extensions previously.

  5. cohen77 says:

    I think it’s a great idea to use Nuget for this kind of use case. A blog I read some time ago had a collection he called SPOT (Single Point Of Truth), where he shared (through a network share) a company wide collection of these files. The idea of maintain this SPOT in Nuget looks great.

    We are only talking about those small utility methods/classes that are too small to put in a separate assembly, need some project based tweaking and are needed in multiple projects.
    On the other hand a library like massive is better forked so you can still get updates from origin (if any), keeping you in sync with bug fixes.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s