A front-end developers predicament
Front end development is still largely under-estimated in many organisations. It can be hard to gauge the complexities involved in developing simple features.
Front-end has grown extravagantly complex over the past couple of years. It is an ever-changing technology stack, however, at many levels, it's still underestimated in many organisations.
There's a lot that goes into a front end development. Brandon Morelli has done a great job of showing the level of complexities in the path to front-end development in his blog. On top of that, I would like to add further responsibilities like security, performance, deployment, etc.
In fact, a good front end developer is closely involved with both the UX and Backend design process. They have an imperative knowledge of API design and User experience since it closely influences their development process. Especially when working in startups, they might actually own the UX portion completely too.
Hopefully, this gives a wide view of a front end developer's job profile.
Considering the job profile of a front-end developer, let’s consider a small task on the UI in a typical work setup.
Hey, I need you to add a button here. When someone clicks the button, update his credentials. It's a pretty simple task, hope it could be finished soon. Can you give an estimate .
You think of the requirement and your mind runs down a diagram like below.
Now as an experienced developer, you know it is dangerous to give an estimation. You can’t assume the system. So taking into consideration the various factors which can go wrong and adding some buffer, you will give an estimation.
Your present project is about to be finished this weekend so you are expected to work on it from next week.
The manager intimates the stakeholders with your estimated dates by adding some extra buffer time and then expects you to deliver.
At this point in time, with this limited information — the expectation is that things will move fast and we will have it go for production in next weeks go-live cycle. You also feel that with the given information, it should be not so difficult.
Understanding the difficulty
You have now started working on this new requirement. Let's look at the task involved to add this button.
- Since the button should be visible only to a certain group of people. You realise that there is no system in place to manage permissions. Being a good front-end developer you decide that you need to create a solution to manage permission possibly making it future proof.
- The view which should render the button is replicated in various templates. Depending on various conditions, different templates are rendered. You need to make sure that the button is safely placed across all these templates. This adds to the extra challenge of testing all the scenarios in which the template changes and make sure that your button is rendered fine in all cases.
- This also adds to the burden of making sure that your changes do not affect any other scenarios in the template. There may be certain sets of conditions were even if the template is rendered you should not render the button. You note down all the scenarios and discuss with the customers to understand whether the button could be shown in all cases.
- Also, you did not take into consideration, the problems with debugging your application in the new system. It seems that the build takes a long time and local setup is not possible. Thus, your changes require a lot waiting time before a line of code could be tested.
Handling Button States
Your usual responsibility for handling the button’s states looks as follows.
- You need a loading experience for the button click. You look for existing solutions for loading experience but find that these solutions are poorly designed. Thus, you need to create a reusable experience for the same.
- In case the operation failed there should be a way to notify the user for failure and ask him to try again. You see that presently there is no notification system in place. Now you have the added responsibility of creating one.
- If the API is successful, then the UI should change to show the updated information that the user just saved. There is an existing page, but it does not take into consideration use cases around showing updated user information. You now have to modify the page to show this information.
After looking at all these requirements, you intimate the extra work needed to get the job done. At this point in time, your boss knows that the tasks could delay by a few days. He expects you to stretch a bit since he has already relayed the timeline to higher-ups and any delay would have further repercussions on other projects.
The next stage of problems in integrating API
- While your colleague is working hard to finish the API, he finds various problems with the existing system. The API would require various information from the UI in order to complete the transaction.
- After looking much deeper, you realise that some of the information that the API needs is not available with you at all. It scattered across various pages and its difficult to route this information to your page safely. You have to now define a strategy to make this information available to your component safely
- Now there are changes required in multiple places to get this information to you. The scale of the project is growing and it's difficult to convey this to your manager since according to him, you have finished the UI and all you have to do is integrate the API.
- This also causes your image as a responsible FEE being questioned and you might have to, in future listen to an argument during your appraisal/meeting that you took such a long time to implement this feature which looked so simple to everybody.
As you could see, A simple button can go through these many problems. And if your system uses various frameworks, then there is an added responsibility of handling the states based on the f/w used.
When I had first entered the world of FEE, adding a button was relatively simple and I did not think through all the above scenarios. However, over time, my experience has dwelled in me to consider the difficulties of these situations.
The Final list of tasks include
- Creating a system to handle permission
- Creating a notification manager to handle the notification.
- Changing existing HTML templates to handle showing button.
- Handling button states based on various conditions and existing utilities.
It is common to have the effort underestimated by peers when the only thing visible is a Button. It's difficult to convey the number of design decisions involved and the frequent iterations you had to do on your code.
Unaccounted tasks
Though the above list sums up the amount of design and code issues you needed to solve, there are additional tasks unaccounted for which also consumes a lot of the time.
- Frequent discussions with your UX guy: Usually the debate between UX and UI developer is what can be done and what cannot. While creating the button experience, the system's vulnerabilities were not taken into consideration. Some styles and placements could not be made due to the lack of structure in the HTML. As a front-end developer, you try to come up with a solution that is plausible and you have the added task of convincing the UX developers and customers to accept your solution.
- The API design many times may not conform with the requirements on the UI. There is the additional burden of conveying the backend developers that their model of multiple APIs is not feasible since a failure in the latter API could not be handled on the UI side safely.
- UI is a field where everyone has an opinion. UI change requests, especially last-minute UI change requirements are pretty common. And sometimes it can be overbearing too. To modestly handle these requirements and making sure that your customers are happy is a quite darn hard task.
- CSS is a headache for front-end developers too and can be pretty hard to give the right animation or the right placement. There is a lot of that goes in to make things look right. Sometimes the whole layout may be needed to change just to have all the text alignment in the right fashion which goes unaccounted for since the final output is negligible.
- There are also other things that we need to work on before releasing to production. The below considerations may not be applicable to present scenario however, it’s quite common that a front end developer has to address these issues.
- Modeling data.
- Handling display on various devices.
- Rendering considerations.
- Latency considerations.
- Caching and Performance consideration.
Hope i was able to convey the predicament of a front-end developer with this write up.