Apr 12 2012
Apr 12

One of the greatest aspects of Drupal is the outstanding community of Drupal users and supporters that constantly work to not only make the software function better, but to make your overall experience using it better. With Drupal, that experience has many opportunities to extend beyond the electronic world and into the real world by way of DrupalCon and regional Drupal meetups. Prior to moving to Portland, Oregon, I had the privilege of coordinating the Denver Drupal meetups and have been able to visit other meetups. While all regional meetups have their own local flavor, they are all share a welcoming atmosphere... and the Portland meetup is no exception.

April's Portland Drupal meetup kicked off with Voodoo Doughnuts (courtesy of the Drupal Association), followed by reports from DrupalCon Denver. Some of the highlights that Portlanders mentioned include:

  • Drupal 8 is being built upon Symfony! Symfony is an open source PHP framework that will replace some of Drupal's low level code with stable, optimized code and allow for better and faster Drupal development. One analogy presented at DrupalCon was: Symfony is to PHP as jQuery is to JavaScript.
  • Drush 5 was released during DrupalCon. Did you know that you can now install, configure and run Drupal (including the web server) with just one command?
  • The Education Unconference was a huge success, not only as a one day pre-conference event, but continuing discussions and BoFs throughout the entire week. The overwhelming positive feedback has prompted discussions about more education inclusion for next year's DrupalCon Portland.
  • DrupalCon is coming to Portland! Just in case anyone hadn't already heard, we had to mention it again.

Following the highlights, Jacob, Neil and Stephanie talked about what DrupalCon Portland means to the local community, how Portlanders can get involved and a bit about the process of hosting DrupalCon. It's a lot of work (even with the incredible support provided by the Drupal Association), but the Portland community is excited to jump in and make DrupalCon Portland the best one yet. If you'd like to get involved, fill out the volunteer form.

With the air still buzzing with DrupalCon talk, we headed over to The Lucky Lab Beer Hall for food, drinks and continued discussions. For information about future Portland area meetups, visit the Portland Drupal Groups page.

Mar 28 2012
Mar 28

This past week at DrupalCon Denver, I attended a wonderful BoF on project management. The session started as a conversation about the complexities of Drupal project management. As we collected a bulleted list, one item in particular from our list stuck with me:

In Drupal development, fixed budget projects exist in an instantaneous sense, but in reality evolve constantly.

One can never account for every unknown on any given project, even when given an infinite amount of time. This idea captures the typical project process exceptionally well as Drupal (and its community) rapidly changes and improves, but we often stumble on the "two steps forward, one step back" phenomenon as a part of this. How can we account for these external risks and explain this phenomenon to our collaborators in the project process? Without firm understanding of this concept, the frustration is likely to mount for all parties.The illusion of moving forward by several paces only to jump back detracts (sometimes entirely) from the fact that progress has been made. This often leaves development teams discouraged and clients, stakeholders and collaborators neglected. As project managers, we're posed with bridging the gap. But how?

Because sometimes modules become abandoned, patches never get merged, and other dominant features crop up, it's best not to guarantee the use of any one particular module, installation profile, distribution or any other kind of feature, but rather an encompassing functionality. For example, instead of specifying the use of the ShareThis module, specify the functionality for users to share pages with members of their social networks. Not only does this get at the meat of the problem we're trying to solve, it explains it in language that our stakeholders will understand, and it won't lock the development team into a dead-end in terms of solutions architecture.

At this point, I can hear site builders and business developers alike saying to themselves, "You expect us to account for building this feature from scratch when there's already something out there that does what I want? That will multiply the size our estimate!" The answer is: not necessarily. Obviously, the Views module is not going to be abandoned any time soon (and if it somehow is, there better well be an jaw-droppingly awesome successor). It really depends on the strength and the state of the feature the developers wish to incorporate, and how cutting edge the stakeholder wants to be. The most cutting edge stakeholder will likely be understanding of the two-steps-one-step phenomenon, so it's a moot point. Those who aren't looking for the shiniest tool in the toolshed should be happy to settle with something that is tried and true. As for those who fall in between, consulting on a feature-by-feature basis will likely get you what you need to accomplish the project: "We could go wtih module X which is currently the standard, or we can try module Y which seems to be up and coming for such and such reasons, but may have risks involved as it's still in its early stages."

A graph of Everett Rogers Technology Adoption Lifecycle model. Drawn in OmniGraffle and then trimmed in Apple Preview. http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.pngAnother great resource to determine where a particular feature is, and where it is going is by consulting the good old technology product cycle diagram (More about the product life cycle on Wikipedia). The development team should be able to place where the feature falls in the product cycle. If they can't, then it's probably not a safe bet. Anywhere at the tail end of a growth phase or in the maturity phase is ideal. This diagram will speak to many clients, stakeholders and collaborators in a way that they will understand. If they see that the module they're interested in is in a decline or an early growth phase, they should be able to understand the consequences with little explanation.

A cry I hear coming from the coding side of my psyche is: "Modules and other functionality can't be swapped out so simply-- they aren't interchangeable. What if the module we intended to use is one I'm familiar with, but the one we end up going with is completely foreign to me?" This begins to get into internal risk mitigation and recognizing the skill set of your team. Skipping over the complexities of that (enormous) topic, before selecting a module and getting gung-ho about it, give your developers time during the design phase to familiarize themselves with the options, and gain confidence in their ability to manipulate them to suit the needs of the project. If they're not confident in this before the design is solidified, they may as well be building the feature themselves. How this affects budget, especially with regard to an increase, will need to be discussed with the client, and the budget balanced accordingly.

In the end, by avoiding specifics and focusing on goals (while still emphasizing the feasibility of the target) in the sales process gives the design and development team the freedom to accomplish the goals in the best way possible in the moment. If uncertainties arise out of product life cycle changes, the path forward should be determined by the stakeholders, so long as they understand the consequences and the available options fit within budget (which could encompass an entire blog post on its own).

All in all, my mind is still churning the ideas exchanged during the brief 15 minutes in this one hour BoF in the three day conference and I can't wait to contribute again to the DrupalCon experience (next time, at home base!) in Portland in 2013. Looking forward to seeing you all next May!

Image: A graph of Everett Rogers Technology Adoption Lifecycle model. Drawn in OmniGraffle and then trimmed in Apple Preview. http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web