What is in a name – "Bundles" and "Application Blocks"

 image blocks

As many of you know, recently we’ve been shipping a set of deliverables that we’ve been calling tentatively “bundles”. Since we first came up with the name, we’ve been having a ton of debates internally(No we don’t have a ton of free time on our hands). I’ve had several lively discussions about this with folks including my boss Shaun, Don, Blaine, and Ed (no longer in p&p) and our customers. The crux of those discussions was not so much about why we chose the name, rather it was more about why we didn’t choose “Application Blocks”. The answer is based on the community feedback that blocks are perceived as too heavy, and too complex. Traditionally what we’ve been calling blocks are libraries that implement a provider pattern, are driven by configuration, etc. Notable examples are the blocks in Enterprise Library, PageFlow application Block, Composite UI application block, and the list goes on. Honestly, I don’t think people love the new name (we know we don’t), but what seems to have resonated well is that its different than the way we were doing things before.

The problem though is the name. I mean at the end of the day, what is a bundle anyway? The idea was that it’s smaller than our traditional deliverables, and you can have many of them. But it doesn’t really go that well with the notion of developing software.  Application Blocks on the other hand fit perfectly as representative of the building blocks of your solution. This could be at either the architectural level or at the software component / library level. In actuality when you look at the new things we are calling bundles, they are really Application Blocks in the true sense of the word, rather than in the derived sense that blocks have come to mean.

So where am I going with all of this? Well, what if we decide to give Application Blocks a second chance, and widen their meaning to what their original intent was.  This means they are truly building blocks – guidance. They might contain reusable libraries in them…or not. The patterns they contain will certainly be reusable. The point is that you can take the guidance and put it together in meaningful ways in order to form solutions.

Would that work well for you? If not, what name would? Let us know.

Comments (6)

  1. Can I start a petition to call them blocks? Me and JD Meier always discussed the desire for blocks to go in this direction; not in exclusion of the larger ones but yes in the intent of capturing the quick wins that would help you ‘finish the job’ better and faster.

    I love the direction and intent of the bundles in simplifying guidance and making problem/solution pairs more modular. I can’t wait to see more, and would feel ‘blocks’ is a great metaphor for them. I do acknowledge that it means that the brand would need to be ‘reeled in’ from the perception caused by the larger ones. But I also feel that developers would empathize with extending the identity in the direction of smaller/simpler/faster… "The AJAX autocomplete block" – to me sounds like get it, use it, done.

  2. gblock says:

    Thanks Ed. That means a lot coming from the person who coined the term in the first place 😉

  3. Chris Staley says:

    Glenn, I can’t help but feel you are a little biased based on your name.

  4. Jarod Ferguson says:

    I like the term blocks better.

  5. Derek Greer says:

    I definitely prefer the term "blocks" to "bundles", but if you want to break completely from the term then my vote would be for using the term "library".  Use the term "block" or something else to denote the whole package (the library, guidance automation, documentation, quickstarts, etc.), but just refer to the actual body of code as the "library" (e.g. the Validation Library, the Composite UI Application Library, etc.).