Drupal Fire - Quick Roundup from important Drupal blogs and sites
Drupal is a great tool for creating a site. It has lots of modules and functionality that allow you to build interesting and complex features. But sometimes those sites lose their relevancy. It's a site for an event that has passed, for instance. Or a site for a topic that was really important at one time but now is mostly useful as a reference for the content it contains. Or it's a site you just don't have time to keep on top of.
Recently, Anthony Ferrara has been posting a periodic "Beyond" series about software design philosophy. Some in particular have hinted at concepts I've been pondering as well. With his blessing, therefore, consider this a continuation of that series.
PHP 5.4 is not exactly new, but it's finally starting to see actual usage by a decent number of people. Its most notable new feature is Traits, which in PHP are implemented as, essentially, compile-time copy-paste. Conceptually, though, they're a way to mix functionality into a class without using inheritance, and without requiring a separate distinct object for composition. (At least in PHP; the term "trait" appears in other languages for similar but subtly different tools.) That's not to say that they're a surrogate for composition; they most certainly are not. They serve a different purpose, that is, providing code for a class to reuse without using inheritance.
Recently, I was reading an article discussing the implementation of inheritance, such as it is, in Go, Rust, and other new-wave concurrent languages. (Thanks to twistor for helping me track down the link.) It made an interesting point that crystallized for me why it is I am so excited about traits. Specifically, it noted that there are not one but two kinds of code reuse: interface reuse and code reuse.
It is not uncommon to want to assign a role to a user after they have been a member-in-good-standing of a site for a period of time. Perhaps this role will grant them access to do some content moderation, or gain access to new features like voting on posts. The Role Delay module was created for just this purpose, and it fulfills its 'role' admirably.
As you may have heard, Drupal Dev Days is going back to DrupalCon Europe 2008's host town Szeged, Hungary on March 24th to 30th, 2014! This is the ideal place for Drupal Dev Days, a whole week of sprinting with learning and participation opportunities plenty on Drupal coding and all the related technologies involved. Here are five good reasons to register for this event now:
- It is the biggest distraction-free sprint to work out remaining issues in Drupal 8 in the whole year. The sprint runs from Monday morning to Sunday night. Szeged wants to provide enough but also be out of your way to be awesome! For example, we booked the same venue up until midnight each day.
- We believe it is essential for a successful core sprint to have core committers on location. Szeged will have Alex Pott and Nathaniel Catchpole with Angie Byron supporting from home while we sleep. If you are a core developer in any capacity, having these two great leads directly at the same place is an amazing opportunity.
- Of course there is no requirement to be a core developer to attend! If you want to join the list of almost 1800 Drupal 8 developers though, Drupalize.me is flying in Joe Shindelar and Amber Himes to deliver the Community Tools Workshop to get you on board with all the tools and processes used in Drupal core and contributed module/theme development. Great new skill to have under your sleeves in 2014. There is not much hard about it once you get started.
- We are taking the BADCamp/DrupalCon labs concept and provide options for speakers to deliver 2 hour and 4 hour long workshops for a fuller deep-dive on development topics. Even if you don't want to be a developer of Drupal itself in any capacity, there is a good chance that if you earn money with Drupal, you would benefit from some of these deep-dives. This is a unique format that other events don't offer. (Admittedly we are short on submitted sessions so far. If you, yourself would love to deliver such a deep-dive or a regular session, see http://szeged2014.drupaldays.org/program/sessions, submissions close on January 15th (in 12 days)!)
- Szeged is a great cozy town! Many of those who have been there in 2008 asked us repeatedly to organise a come-back opportunity. Here it is and it only costs 30 EUR now! See our interview video on Szeged experiences at http://szeged2014.drupaldays.org/community/attendees. You won't regret coming.
With all these great reasons, what are you waiting for? Buy your ticket now at http://szeged2014.drupaldays.org/buy-your-ticket
In this episode, Addi is joined by Todd Nienkerk of Four Kitchens and Brian Skowron from Lullabot to discuss "consultancy scrum." We start off by briefly explaining what scrum and agile are, and then dive into the lessons learned about using this methodology in a client/vendor relationship, versus a completely internal product team.
We are right to be worried about budget. Multiple studies justify our concerns: In 2004, the Standish Group reported that 71% of IT projects were over budget, while University of Oxford researchers found that large IT projects run 45% over budget, and an article in the Harvard Business Review in 2011 reported average overrun of 27%, but also brought up the fact that as many as one in six of the projects experienced cost overruns of 200% (they called these “black swans”... hmmm, pretty.)
Why Projects Go Over Budget
Causes for overruns typically fall into the following categories:
1. Underestimated complexity and/or volume.
Additional Volume: More touch points mean more time, and in projectland, time equals money. More content to migrate, pages to edit, unique widgets to create, more slight variations of the same layout to code and more rounds of revisions to address. Of course there are efficiencies when executing similar repeating tasks, but even slight underestimates of volume can mean extra chunks of budget. Conducting a content audit and creating a complete set of wireframes can help realistically quantify the work being done as part of scoping and requirements gathering.
Additional Complexity: It can significantly impact your budget when the level of effort required is discovered to be more than originally expected. This can come from underestimating, being too optimistic, or not being fully able to estimate unknown factors - such as new technologies, external data sources from yet unintegrated third party systems, or even just complicated workflows that are tricky to fully conceptualize on paper. When creating a project plan, it can help to flag these types of items as ‘high risk’ and consider allocating additional time to them for research and prototyping.
2. Assumptions about the feasibility or effectiveness of solutions.
Walk a mile in someones elses user journey before jumping to feature implementation conclusions. Solutions that are suggested before the target problems have been fully uncovered have the potential to put a budget at risk. A designated project planning phase allows time to collect valuable information from stakeholders and end users which can help maximise return on investment. If you begin designing solutions or committing to specific user interfaces and features before workshopping issues and goals with user experience professional or technical experts, you run the risk of making incorrect assumptions and often discounting some simple, yet effective work aournds. A full, 360 degree project discovery must involve multiple stakeholder groups, both quantitative and qualitative analytics, subject matter experts, communications and marketing, IT and end users.
3. Not allocating adequate time for non design or development related activities.
Creating a realistic budget means including time for all project-related activities that will help move project forward. Plan on budgeting between 10-25% of total project hours for each of the following line items:
- Research and planning
- User experience design
- Information architecture
- Project management and communications
- Quality assurance and testing
4. Changes to scope made when constraints are realised.
Drupal allows for adding features quickly, but often requires additional custom work to meet specialized or complex business requirements. Sometimes it’s only after features are built out, populated with content and tested out by real users is it discovered that they don't fully meet expectations or needs. When this found to be due to limitations in available community modules, the options are a) to simplify the logic and/or adjust the system so that it works within the constraints or b) add more budget to custom build precisely what is required. The best way to avoid these difficult choices late in a project, is to carefully define only the “what” (the action that is required by the user to make the site suscessful) and not the “how” (or they way the system should address the business problem). A good understanding of project constraints combined with a flexible approach to implementation will help open up possibilities for cost-effective solutions.
5. Changes to scope when conflicting priorities battle it out.
It can be challenging to set realistic expectations with large stakeholder groups, especially on a long overdue project. Everyone is excited about the blue sky of possibilities - and at the beginning almost anything is possible - until budget comes in to play. A project that needs to be all things to all people is in grave danger of going over budget - especially if there isn’t strong leadership to help direct priorities. A focused project vision with strong leadership and a designated product owner who has the authority and personality to be able to act as a disciplined gatekeeper to a barrage of requests is the best scenario for projects that need to answer to a large group of interested parties. It’s also important to have a clearly defined change management process and acceptance criteria, especially for subjective or difficult to describe aspects of the product, such as visual design and ‘ease of use’.
Five keys to controlling budget
In the end we just want to know if we have enough budget to get what we need. No one likes surprises or an ever-expanding bill, so how can we protect against the very real danger of things costing more than hoped or expected? Here are five key factors. These best practices will need to be approached differently depending on whether you are in the planning or development phases of the project, but following them from initial specification writing, to monitoring and controlling buildout, through to quality assurance and launch will yield excellent results. For optimal sucess, be sure to also seek guidance and input from a multidisciplinary team who is experienced in budget control techniques.
- Clearly defined and well-researched target problems
- Realistic project goals
- Good understanding of project constraints
- Clearly defined change management process and acceptance criteria
- Strong leadership, direction and product ownership
Obviously, creating a realistic budget in the first place will make it easier to manage expenses later, in the development phase. For more information on best practices for requirements gathering, check out our two-part blog post on the topic.
~ Vanessa Turke is Director of User Experience and a Senior Project Manager at Drupal Connect
Happy New Year to all. 2013 was a year of many changes. These were professional, personal, and on a more macro level. I had recently left my job with Trellon to pursue contract work. We had just finished renovating our kitchen - just in time for a New Year's Eve party that involved a large percentage of guests from the Drupal community. Our little dog, diagnosed with mast cell cancer, wasn't expected to live for much longer (spoiler - he's still kicking it with us). Congress, in the United States, continued to be deadlocked culminating in a partial shutdown of the government, and a populace that was sick and tired of 534 people who simply could not agree on anything. There was a seriously flawed rollout of the healthcare Website, which as a Web Application professional I found fascinating.
I thought that sharing some bits and pieces from my life over the last year might be fun. If you feel interested enough to follow along my geeky and Drupally year, that would be just fine.
I had started working as an independent consultant with several clients late in 2012. The biggest one was 5 Rings Web, where I was consulting as the COO and managing the project management side of the shop for my good friend Lindsay Ogden. 5 Rings is largely a Drupal shop and I started by auditing processes and helping the group of excellent developers and designers organize in a more efficient manner. I was lucky to work with some terrific clients supporting existing Drupal sites but also defining some complex architectures for several companies and helping the team organize around Agile Sprints to bring web products to market. I am very proud of the work I did there when I was more heavily involved in working with them. Some how I managed, while doing operations for both Vintage Digital and 5 Rings to write a blog post on Managing Multiple Drop boxes
In March the community found out that Neil and Marta were leaving the Drupal Association in a restructure of the organization. This came as a shock to many. There were those who had really come to know Neil and respected his hard work on the Drupalcon. He had a pretty rough go of it with Drupalcon Denver in 2012 as he better integrated into the community. I was amongst those who were deeply saddened by the departure. Holly reached out to many in the community, including myself, to reassure us.
drupalrecap2013Happy New Yeardrupal associationCrown Pointe Academydrupalcamp coloradoBADCampAten Design Group5 Rings Webvintage digital