Debugging Front End is not only a matter of tech

Over the last few years, front-end development has evolved at a fast pace and this has required us to review the way we work, the development tools we use, the way we share knowledge and information. It’s definitely time to make order among shared technologies, tools and methodologies.

At this point, we must spend some time to enlighten any possible critical issues not only in technical terms but also in relation to the needs of our stakeholders and the way we interact with them (other front end devs, backend devs, UX / UI team, QA testers, functional analysts, clients…).

Long story short…

It’s time to debug our work process

In order to better focus on critical issues, we can start by zooming out our perspective and take a look to a typical project life cycle (which the scheme below summarizes), so that we can better figure out which role front end engineers play throughout this process and what they can actively do to make it more efficient.

To make this analysis simpler, let’s assume to be working on a brand-new project starting from scratch.

This graph may suggest that all front end activities are mainly executed between Design and Testing, but as you know, the reality is far more complex than a linear succession of steps. Most of the time, the software development process is iterative and incremental, and there are several ways front end engineers can actively be part of it.

Sometimes they call us painters but that’s not really fair.

Whenever we want to make a parallel with traditional jobs, I think we can also be compared to bricklayers and interior designers as well. Why?

Front End Engineer is the new bricklayer

Front end developers are responsible for building ‘houses’ in accordance with ‘construction plans’. As bricklayers, they know different building materials and uses certain main working tools. They work in a team and it is therefore essential that they know how to work well by collaborating with all the professionals involved.

Starting from this definition, we can ask ourselves some questions to successfully drive out the main critical issues.

1. What do we need to start working on?

As previously mentioned, we need a construction plan, that should include:

• Requirement analysis
• UI Mockup and Visual Design defining a visual language
• Design Prototype to enlighten flows and interactions
• A collection of the required assets

Here is where we may found out the first criticality.

What generally happens is that all this stuff is provided at the very beginning and it does not evolve together with the project. It’s more like a portrait of the project at its starter time, this way ending up to be a constraint.

The reality suggests that the design process is iterative. It is closer to the process of creating an animated design, as well as a movie.

The first step should look like a draft of a storyboard, which is progressively modified, up to the final version, with the cooperation of developers, designers, clients, …

The design process is characterized by the fact that during developments it’s often necessary to make changes, fixes and/or improvements and this consistently occurs. In order to support this iterative flow, the construction plan needs to be reviewed over and over. Otherwise, mockups and prototypes can no longer be efficiently used as validation and testing tools.

Here’s where tools like Abstract, Living Style Guides, Storybook can come in handy.

2. What do we use to work?

Generally, we don’t start a project from scratch. That would be crazy! As soon as the construction plan is ready, we use to collect all the working tools which make us fasten and give a boost to our productivity. About this topic, I recently came across this article by my friend Sebastiano Guerriero from CodyHouse: Everyone uses CSS frameworks, which I suggest you read.

One of the main development tools we can use is the front end framework, which is a starting codebase that allows us to avoid doing the same things over and over again on every single project. This starter code must also be representative of a shared standard, must be maintained and documented.

First thing first, we should ask ourselves whether our starter code is really useful. In order to properly answer this question, we can start from the definition of usability:

Usability is defined by the ISO (International Organization for Standardization), such as the effectiveness, efficiency, and satisfaction with which certain users achieve certain objectives in specific contexts. In practice, it defines the degree of ease and satisfaction with which the interaction between man and an instrument takes place.

At this point, you can ask yourself:

Is the framework I’m using really usable?

Starting from the previous definition, we are able to identify the main bugs that affect the usability of our framework:

• It may contain obsolete and deprecated code
• It may be based on poor documentation and maintenance process
• It may suffer a lack of standards and conventions

How we can fix these issues to increase effectiveness, efficiency, and satisfaction?

Let’s start by decluttering our code!

Remove things that you do not use so that you have more space and can easily find things when you need them.

Our main goals should be to:

• constantly clean up and modernize our FE codebase;
• define a coding convention and create a consistent look to the code, so everyone would be able to easily understand and maintain it;
• create and update the documentation (if you don’t document it, it didn’t happen!);
• define a maintenance process.
• Actively contribute to the definition of a Design System.

3. How do we cooperate with the other people involved?

When working in an iterative way, it is essential to cooperate constantly with all the figures involved. This is necessary for:

• evaluating the design changes step by step according to the needs and / or limits identified.
• being all up to date on the statement of work
• always being aware of product evolutions. This also benefits test activities, since it prevents that the QA tests would be based on the prototypes produced at the starting time and no longer keeping track of the next occurred variations.

Fighting with the people we are supposed to work with to reach the common goal is counterproductive and it’s always a waste of time and money.

There is plenty of communication and sharing tools out there (Slack, InVision, Zeplin, Confluence) so let’s just give them a try and find the ones that better fit our needs.

About that, I suggest you read this article: Best practices for designer-developer communication.

There’s no secret recipe or magic mathematic formula to make us 100% sure that we will find the ‘bugs’ related to our workflow. As it may seem trivial, what is 100% sure is that we have no chance at all to ‘debug’ it if we don’t come out with some questions about the way we work all together.