Every Drupal website we work on, regardless of client, pretty much follows the same process: A Drupal instance is set up, modules get installed, designs are translated into themes, and business logic is applied where needed. Rinse and repeat. Simple, right?
Well, not really.
There will always be things that prevent projects from being just another cookie-cutter website. Teams change, and so too shall preferences on how to do things. There are those who have a certain bias towards or against certain ways of doing things. Then there are those who build things that nobody else knows about. There are those who chase after or stay away from the new and shiny.
In any project, in any team, in any company, there will always be some form of random chaos – which is perfectly fine. That’s just how the creative process works. But when this chaos is left unchecked, it can cause a disconnect between team members and projects. Team members aren’t on the same page, projects are dreaded and avoided, and everyone starts to speak in whispers.
This harms morale, productivity, and therefore, efficiency.
Let’s talk about efficiency
Working in a boutique web development shop, time is literally gold. The faster things get done, the bigger the margins, and the earlier developers are freed up to work on other projects. To make this possible, tools and processes need to be:
- Repeatable: Start new projects without recreating the tools and processes of the previous.
- Scalable: Resize teams arbitrarily without incurring management and training overhead.
- Maintainable: Assign anyone to legacy projects, get them up to speed and fixing bugs quickly.
To achieve these goals, everyone needs to have a common understanding of how to do things. A set of guidelines. A set standard. A framework. A common set of tools and processes to get things done.
Now this may feel very rigid at first. Some even compare this to being given a very thick company manual on the first day of work. But think of it this way: Having a known and common way of getting things done enables everyone, regardless of position, seniority, or even skill level, to easily contribute work and share information.
And one way of doing this is by using open-source tools and adopting best practices. Here are a few ways that we find open-source tools improve our efficiency and get the most out of any project.
1. Adopt community-accepted conventions
Developers tend to bikeshed over development practices, like the use of spaces versus tabs, semi-colons versus no semi-colons, collapsed versus new-lined opening brackets, and so on. This could easily turn into days, months, even years, of debating over which one is better – often for very little benefit.
But the conversation can be over in five minutes if everyone just adopts one community-accepted convention and sticks with it.
I use Standard JS and a matching EditorConfig on my personal projects (two-space indents and no semis ftw!). But at work, we work with Drupal and other Drupal developers. Drupal comes with its own guidelines on how to write code. So even if I have my preferences, I have to set them aside in favor of being consistent with other developers, and the community as a whole.
2. Don’t reinvent the wheel
Developers are the type of people who break things to learn how they work. One such occurrence is when developers reimplement tools. But sometimes, this is taken a wee bit too far. Coupled with a bad case of tunnel-vision, developers end up burning more time reinventing things than being productive.
But instead of reinventing things, why not use something that’s already working well?
I love tinkering with things, and I’ve written my own tools to solve problems. But at work, we don’t have all the time in the world to do that. Instead, we use available tools like Angular, Spring, Drupal, and Bootstrap. These not only provide us with everything we need out of the box, they also save us time by allowing us to focus on building the more important things.
3. Avoid tribal knowledge
Writing proprietary tools and processes have risks. A dangerous one is when knowledge is concentrated only to a select few. And when these select few start leaving, it’s often a mad scramble to document these tools, or have someone else get up to speed on short notice. We all know reading through undocumented source code of a former developer is a less-than-fun exercise.
This does not have to be the case, especially with the open-source tools available today.
These tools and their documentation are openly available. This means anyone can learn them. As a side-effect of this openness, a talent pool is immediately available for hiring. If an app’s UI is written in Bootstrap and the UI developer for that app leaves, it’s easy to get another developer up to speed by pointing them to the documentation, or hiring an already proficient developer.
Conclusion
Working in a boutique web development shop, developers come and go, projects have a finite time-frame, and assignments can change on a weekly basis. We find that using open-source tools and best practices allows us to be more efficient in our projects. A common understanding on how to do things is much more efficient than coming up with a unique brew of coffee each morning.
Learn more
- What I Learned from the Mind Behind Drupal: Reflections on DrupalCon’s Driesnote, by Caroline Casals
- Contact GovWebworks with any questions
