Mistakes I Made Implementing a Complex React Feature
During my day job I am a Frontend Developer at a rapidly moving Chemistry startup. We are growing quickly as a company and there is a need to build out many UIs for internal users.
I had to work on a fairly complex feature recently which was deemed business critical. I worked on the implementation pretty much by myself as the team was spread very thin.
(Just to note, we are using React and Typescript with the Mantine component library on our Frontend. We are using Tanner Query for most of our api calls and a little bit of Redux for handling complex frontend state management).
I wanted to take some time to reflect on the implementation of this feature as I felt it didn’t go quite to plan. All in all I thing the first version of this feature landed ok but it could have definitely gone better. This is my own version of a retrospective and hopefully by sharing this with the community I can help others who may be in similar situations.
Some Context First
I can’t say too much about the feature that I built as this is confidential to the company. What I can say is it was very specific to Chemistry so expert knowledge of Chemistry was needed to help create this feature. I was therefore working closely with chemists. The basic premise of the feature was to provide custom user interfaces that enable chemists to enter information and then that data was to be used further on in the process to create other artefacts. Therefore the validity of the data was very important.
Starting Very Basic
One thing I think we did well was to start off with a very basic MVP (Minimal Viable Product). I mean VERY basic. We just had a bunch of WYSIWYG editors to capture the text from the users. It was an easy solution and enabled the user to start working, however it gave them way too much freedom in terms of what they could enter.
We needed to capture the data in a structured way and with this first implementation there was no structure at all. This was having a negative effect downstream and making it almost impossible to generate the required artefacts. Therefore, we had to evolve this feature.
Foreseeing All Consequences
This is something I really didn’t give enough attention. I admit it’s difficult, especially when starting on some new feature, to predict where this feature and the data within will have impact within the company processes but it can save a great many headaches if you can give some extra thought here.
For example, with the feature I was working on, it was going to output some data and that in turn was going to be used by another team. At the time, I didn’t meet with this team to discuss the structure of the data they would expect (definitely a mistake).
Why didn’t I do this? For the usual reasons.
- Many things going on at once.
- Focusing more on the UI/UX of this new feature and how I was going to implement the code in the most efficient manner.
- Problem solving tricky client side state issues.
- Not enough time.
- Not giving it enough foresight.
However, now we are in a position where the UI/UX is in a good place but the underlying data structure could be better. It’s not terrible, I did give it some thought in the beginning but not enough. This is now causing churn.
UI/UX and Mockups
Back to the UI/UX part of this feature. One thing I think I did do well was to mockup each section in Figma and go over these mockups with the stake holders. I think this is crucial because an abstract concept of an idea vs seeing how the actual UI will look like and behave are two distinctly different things.
Of course it is tempting to rush straight into coding some piece of UI. However, once you have done this enough times and then had to recode your work because it wasn’t ‘what I thought it would look like’, you realise that mockups are a great efficiency tool.
It allows the stakeholders to visualise what they think they are asking for. It allows you to clarify many details which could easily be overlooked and it can all be done relatively quickly and efficiently.
As a Frontend developer these days who is building out features, I think creating mockups in something like Figma is an essential skill.
Pushing To Production Too Quickly
This was probably the biggest mistake I did and it’s such a classic. There is always this push and pull between Business and the Development team.
The Business team want the app live yesterday and the Development team want 3 weeks for building, testing and then more testing.
It’s always a compromise.
However, in this instance I think certain parts of the feature were pushed to users too soon without being fully battle tested. We don’t have the luxury of a QA team so it relies on a few individuals to test out each feature.
We have standard unit tests and Cypress E2E tests but these can only get you so far. Especially in Chemistry where exceptions are the rule! We pushed to production and for the most part it worked as expected but there were definitely a small set of circumstances where unexpected behaviour occurred.
Eroding Trust In Your App
When developing an app you really have to tread a fine line between making progress and maintaining reliability and stability. If you swing too far to make quick progress, then likelihood is you will sacrifice some quality. If you swing too far on the conservative side and compromise on progress then your users will become frustrated with the lack of innovation and their experience on the app not improving.
With the rapid deployment to production and the release of some unwanted behaviours I think on this occasion I swung too far on the progress side and in turn eroded some trust from the app. When users have bad experiences with an app, especially things that end up slowing them down, then they are quick to dismiss any positive aspects of the application.
It also creates churn in the form of Jira tickets, meetings and slack messages which all require ‘time’ to address. However, it’s very hard to quantify this time as it happens across many different people at many different intervals so the cost is not obvious.
If you miss a deadline, it’s very clear cut. If you make a deadline but cause a bunch of churn afterwards that then creates a whole bunch of more work, its not so obvious.
Conclusion
From reflecting on this feature implementation and giving it some thought, I conclude thats it’s much better to give a generous buffer to your timeline when relating to business when a feature will be ready. The reason I think most of the quality errors occurred was because I was in a rush to get this feature out to production.
However, there are just too many unforeseen possibilities when working on anything beyond the most simple feature. As soon as you require other developer’s input this also throws a whole load of unknowns into the equation.
As this wise video states, time estimates should be doubled or even tripled what you initially think is accurate. It’s better to over estimate and deliver ahead of schedule.
Also remember, once a feature is out there it is out there and can’t be taken back. The best features I have worked on are the ones where I have adequate time to think deeply, implement carefully and test properly.
Subscribe to My Weekly Updates!
Enjoyed This Post?
If you found this blog post helpful, why not stay updated with my latest content? Subscribe to receive email notifications every time I publish. New posts go live every Monday at 8:30 AM Central European Time.
What You’ll Get
By subscribing, you’ll get:
- Exciting Discoveries: Be the first to know about the latest tools and libraries.
- How-To Guides: Step-by-step articles to enhance your development skills.
- Opinion Pieces: Thought-provoking insights into the world of frontend development.
Join Our Community
I live in the vibrant city of Prague, Czech Republic, with my family. My blog is more than just articles; it’s a community of like-minded developers who share a love for innovation and learning.
About me
I’m a passionate Frontend Developer specialising in React and TypeScript. My professional journey revolves around exploring and mastering new tools and libraries within the JavaScript ecosystem.
Check out the original blog post on my blog.
