This is the start of a new and ongoing series in which I will address topics that are debatable within the IT industry. I will then attempt to address the topic with my own thoughts on the matter and open it up to discussion with whoever is interested in giving their two cents. There is a tendency in the IT industry for engineers to feel like they have to know it all but the reality is that no-one knows it all and we could all learn from each other. I’ve found the best way to fight imposter syndrome is to let the cat out of the bag, admit that I don’t know everything, and then go ahead and build the software that I’m not 100% sure how to build and enjoy the learning process along the way.
I’ve been in the IT industry for almost 20 years as a software developer, application architect, director of IT for a small non-profit, and now a small business owner. I have a degree in Computer Information Systems and I’ve worked for both large (IBM) and small (non-profit) organizations alike. I’ve also worked across geographies and industries. I even have a patent in the semantic web space! I say all of this because even after all the years that I’ve spent in this industry I still learn a lot each day I’m on the job. In fact, this is one of the reasons I love working in the IT industry so much, I love to learn. My hope for this series is two-fold, first, I suspect I’ll learn something new from the input of others in the profession. Second, I hope to encourage those that might be struggling with what may seem like an overwhelming need to know everything. Every one of us, no matter how experienced can grow in our knowledge and improve how we do our jobs as IT professionals.
The Question
Today’s question is, “when you start a new project, which should you build first, the back-end or the front-end?” This question has come about based on a job interview that I had a while ago. I explained to the interviewer that I was, at the time, working on a React.js front end prior to building the back-end. The interviewer seemed to frown upon the fact that I was building the front-end prior to the back-end. I find that, at least in the IT world, there is more than one way to skin a cat as the saying goes. Whether or not it is right or wrong is specific to each circumstance. There may be good reason for taking one approach and that same approach may not be the best way forward another time. It all depends. In any case, I was thinking about building the front-end vs. back-end first and have come to the realization that the answer to our question today is also that, “it depends”. What I’d like to do for the rest of this post is consider the pro’s and con’s of each option and then leave it at that because in the end it all depends.
The benefits of building the front end first
It seems to me that the biggest benefit of building the front end first comes down to clarity on exactly what you’re data will need to look like. By building out the front end first you come to an understanding of exactly what your data will need to look like in order for your solution to work.
Building the front-end first means that you are going to be more geared toward addressing the needs of the user. Ideally this means that the approach that may be best is if you start both at the same time to make sure that user considerations are adequately considered across the whole stack.
Another benefit is prototyping. You can build the front end and stub calls to the back end. This will give you a quick and clear way to know how your solution will work. This can be particularly beneficial if you need to sell your idea to investors and partners.
By building the front end first, you are establishing a clear expectation for what will be required from the back-end in order to perform the tasks that the application will need to perform.
By building the front end first you can implement end to end testing with a tool like Selenium and stub the backend.
The drawbacks of building the front end first
The immediate drawback I see for building the front-end first is in the case where the solution has few user interactions. User interactions drive the front end. An example for this that comes to my mind from my own experience was a tool that I worked on to process artifacts from an existing system to analyze the system and then generate work products to improve the system. For example, we built the tool and used it to injest legacy Visual Basic code for an insurance company. We then analyzed a canonical form of the VB code and wrote transformers that generated Java to do the same thing that the VB code did. There was not a lot of need, in this case, to consider the UI of the tool just a simple form to point to the files to injest and buttons to kick of the analysis and transformation process.
In a non-agile environment when you have a very detailed understanding of the solution upfront, it may be better to build the back-end first and then build the front-end to interact with the back-end accordingly. The problem with this approach is that it is not very conducive to change.
If you are building a solution with a new library/technology and you’re not sure what the art of the possible is for the back-end, it might make sense to work on the back-end first. At least prototype the back-end in the new technology you are considering in order to flesh out unknowns as a pre-cursor to investing all that time in the front end.
To be honest, it is hard to think of drawbacks but I’m sure there are more.
Conclusion
I think if I had to give a definitive answer to this question I’d say that there seems to be many more benefits to building the front end first. Ideally you build them together but this would require two different teams that communicate well with one another and the stakeholders. That is not always possible. I’d love to hear your thoughts so please comment below with any additional pro’s or con’s and let me know what your experiences have been!