Mar 6 2021

Front-end development is not automatically easy. Project timelines should reflect that.

I’ve had the title of “front-end engineer” in some sort of capacity for almost 9 years now. In these 9 years, one thing has not changed:

“Oh, that’s just HTML and CSS, that’ll take like, 2 days right?”

This could be true, but it is not usually true. We see this in discourse on Twitter, in meetings throughout our workplaces, and in general the vibe that front-end is not really “development”, “engineering”, or “programming”.

Why do questions / statements like this matter?

This sentiment towards a craft really “grind my gears” so to speak. It emboldens the following assumptions:

  • That front-end (HTML, CSS, and JavaScript) languages are easy.
  • That there is no lead time to “getting things ready”
  • That there is no lead time to really get a project into a “let’s go” state.
  • That there is nothing to clean up (if it’s an existing project)
  • That you can write code once and it works and it’s good to go (browser testing across devices is a thing!)
  • That organization and writing clean, maintainable code takes no time at all.

These assumptions are harmful to any craft - but we see it all the time with front-end engineering.

What is a better response?

Timelines are important to any project - I’m definitely not disputing that. Front-end engineers are usually sandwiched between design and back-end engineers - both of whom are usually given a bit of lead time to really understand the problem. Many front-end engineers want to be and need to be part of that lead time / discussion.

  • Ask the ones writing the code
    This might sound wild, but ask the people who are making the changes and adjust your business priorities accordingly. They may waffle on an answer, but their waffling is also a good indication it may take a bit more time than you realize.

  • If you allow time for design, allow time for development
    It is not unfathomable that the time it took to research / come up with finessed designs might be around the same time a developer needs to execute the designs.

  • Give front-end engineers the respect they deserve
    Front-end engineers have to support a wide range of clients, deal with languages that are constantly changing (like, literally, every 4-6 weeks a browser might support something new), and constantly have to watch out for themselves by not painting themselves into a corner when a new design comes across the table.

Design is not easy.

This applies to the actual creation of designs (UX, visual, content, etc) but also architectural design of a codebase. Companies all the time find themselves in a situation where a codebase is not “feasible” to be upgraded because things weren’t thought of when it was designed.

How do you overcome this problem?

Slow down. Take a bit more time to create a scalable system, no matter the language, that can take you from small to large. I’m not advocating for perfection - I’m advocating for sensible and pragmatic development.

Invest in what you’re making - whether you’re a small startup or a company that can throw tens of millions of dollars at a project on a whim.

Allow your engineers this time. It will help you (and your team) later.