I work with colleagues at Georgia Tech at twice-a-month web development help desks, primarily focused on end-user support of Drupal’s steep learning curve. In the four years I have helped provide folks feedback, suggestions, and direction on all things Drupal, I have not yet turned someone away due to complexity – until this week. This week, I learned to say no, and set realistic expectations for support and complexity of a project.
In too deep
Georgia Tech’s web development is highly decentralized, so individual units, departments, and groups have a web developer or point-of-contact. The project in question was started by a full-time employee who dabbled in web development as “other duties as assigned” in addition to administrative duties.
This employee went above and beyond – the Drupal project in question contained workflows, entity references, linked content types, advanced views coupled with field views, and managed a specific set of task procedures. Within the content management system, Drupal, it was akin to building a very specific LEGO set – like, let’s say, a LEGO Star Wars Star Destroyer. It was built correctly, the Drupal way, using Drupal module components while minimizing custom code.
This web application works – and it works to the department’s incredible satisfaction. It works so well that leadership wants additional new functionality attached to it, which coincidentally occurred at the same time the staff member left the organization. As this position was not a web development position, it was falsely assumed by leadership that anyone could pick this up, so the project was moved to the writer and editor for the department, who then came in to the help desk asking for advice and direction.
When I saw this problem come in, my first thought was to examine the scope of the request:
to extend current functionality into a new area and provide user-specific and customizable pages dependent on settings that currently did not exist.
As my colleagues began throwing out ideas on how this new functionality could be completed, I considered a simple query: could this be done by someone without experience within the content management system? In LEGO terms, could I turn my Star Destroyer into, let’s say, a TIE fighter?
These updates would result in a product that would be close to its fore-bearer – it is still a LEGO ship set, that fires laser LEGO pieces, that has LEGO characters embedded. But its form, function, and design is drastically different – and require significant changes to accomplish what on paper looks to be a simple task (“change a triangular ship into a U shaped ship”).
Similarly, this website change would not just be a new view – or set of views. Based on the need, it would require both a strict process workflow to find out how and why pieces of content operate and flow, and then determining how the new requirements would fit into the puzzle. Then, a user would need to translate those new requirements transposed to the workflow into its associated Drupal components, and confirm the changes and initial functionality operated as normal.
At that point – the answer had to be no.
Why say no?
For our volunteer work, it is infeasible with the help-desk windows (twice a month, for two hours) that this task could be accomplished by a variable set of rotating developers over a three month period. Never mind the ramp-up time or the testing – simply coming to terms with the development, scoping out proper functionality from a request, and implementing changes is non-trivial for our developers.
And when someone with very limited Drupal expertise is volunteering to accomplish it, and asking merely for guidance on how to get started, it would be immoral to say otherwise. Consider your first Drupal project with Views – one of Drupal’s core tenants of data representation. Were arguments, contextual filters, advanced filter conditioning, advanced field replacement strings and strategies, or even the view display modes clear? This employee would be diving into that level of complexity, unaided, on a project which has already properly utilized the concepts and expert features. One improper click, like re-initializing a field, could break the existing workflow, Views, rules, and logic baked into the website.
In fact, that was the first clue of in too deep – the first View in question had corrected missing relationships, a symptom of content structure reorganization since the last update of the content query setup. Those ‘corrected relationships’, in Drupal terms, usually means the system defaults outside of contextual relationships and other data connections, breaking the functionality entirely for that connected content.
Yes, given enough time and exposure to Drupal, this employee could likely finish this request. However, if we were to graph that time requirement through pay and neglected other duties, comparable to outsourcing or contract work, the cost savings of initially handing the project off to an expert would be abundantly clear. More importantly, this takes into account the sole first step of changes, with the expectation that the request and requirement may not be accurately portrayed or detailed on the initial ask(s).
Don’t be afraid to give bad news.
At the end of the session, there were enough red flags to point the employee to contract work over do-it-yourself work. The usage of the Workflow module, content types with multiple levels of Entity Relationships, complex multi-tier Views, contextual and user-centric Displays and dashboards, as well as function-specific Rules meant that shaking the website around for new functionality would do more harm than good.
Take the LEGOs above – I would be comfortable shaking the simpler and safer ocean kit. Shaking either Star Wars LEGO kit would result in pieces breaking, flying off, or loosening up inside.
And if either of those Star Wars LEGO kits dropped, well…. better to be safe than sorry.