Front-end technology is a complex, rapidly changing area of specialization. Anyone who works as (or with) a "front-ender", knows that any single topic can be an action-paralyzing process of option evaluation and comparison, ad infinitum. Many teams mitigate the issue by their singular focus on a project. They have one one product, with a defined goal. Whatever process they ascribe to in reaching that goal, the whole team has a dedicated focus.
What happens, though, when a team handles multiple projects, in parallel, on varying technologies? Reliable and accessible front-end technology becomes the best or worst part of the team process.
The Role of the Front-End
The space inhabited by front-end development can be strange and different, depending on the project. In some cases, it may be handled early on, as part of the design for known content. Other times, it may be applied as the final process to aesthetically improve a data-driven application or service. Ideally, a front-end developer has a finger on the pulse of a project from start to end.
Front-end work exists in a middle ground that is impacted by nearly every process in a project. Design decisions can foster or restrict the technology or end-usability before a line of code is ever written. Back-end decisions of handling data, organizing resources, and outputting content can optimize a project, or inadvertently create a pile of development spaghetti.
Theory Meets Reality
My team doesn't fit into the traditional, software life-cycle role. We're a small group of developers tasked with both creation and maintenance of projects across a wide spectrum of web technologies and services. A given week includes multiple content management systems, several separate groups of project stakeholders, and the creation of additional in-house applications from scratch.
Under these conditions, front-end technology quickly becomes either my teammates' nightmare, or the icing on the cake. I've been putting a lot of my focus into creating a front-end methodology that creates more of the latter than the former, and frees my teammates up to focus on their own strengths and goals. There are a few specific goals I have in mind:
Make as much code simple, succinct, and reusable as possible.
Implement and communicate the biggest gains and conveniences to my teammates.
Establish a living and growing front-end standard that will continue to be relevant.
Sort efficiently through technology offerings and deflect unnecessary complication.
Guidance in Practice
Based on those initial goals, we began shaping some concrete deliverables that the team could use immediately. The first was a stripped-down and customized CSS grid system. Mobile-responsive development is a huge goal for a lot of our projects, both current and future. Enabling developers across the team to easily build responsively with just a few class names was a big win.
Suddenly, unwieldy pages of content and data became easier to use, even in unfinished states. Detailed user interfaces can still be handled by dedicated front-end developers, but the pre-packaged CSS massively increases convenience and efficiency on projects across the board.
This custom CSS template was also the first testing ground for internal front-end coding standards. While this had less direct impact across every individual developer, our front-end team members are quickly adapting to a more universal and interchangeable method of code. Ideas like BEM and SMACSS, applied to our existing methods and preferences, have shaped our process greatly.
An initially unexpected benefit to our endeavor has also been interfacing with outside development teams. Being able to formulate simple and documented development methods and deliverable standards has made working with external contractors easy and productive. Code hand-offs seem less like a mystery grab-bag, and more like a professional and organized process.
Always Be Growing
These goals and deliverables formed the initial outline of our work. Even as they see early implementation and use in production, we're actively growing and refining through experience in practice. As we look forward to a steady stream of projects, we can streamline unnecessary code and add contingencies for unexpected needs.
Having living, relevant development resources gives us an advantage on every new project. We don't drag dead weight or black-box "mystery" dependencies into our code, and can meet our goals with precision and confidence. Front-end technology becomes a reliable tool that everyone can access, and the team benefits from that capability together.