Do You Really Need a Full-Stack Developer?

Photo by Oskar Yildiz on Unsplash

Web application development involves a lot of activities such as:

• Capturing user stories
• Creating mockups
• Developing core components
• Building prototypes
• Developing a working application
• Deployment
• Testing
• And eventually acceptance by business users.

In the whole lifecycle of web application development, there are many skillsets involved. In the recent past, we have been seeing a high demand for full-stack developers.

Consider a cricket team (or any sports team). We need specialist bowlers, specialist batsmen/batswomen, and few all-rounders. Sometimes, all-rounders help to win a match or even a series. But, there is no team without specialists. Full-stack developers are necessary but not sufficient.

Wicket-keeper batsman/batswoman is your developer who could setup CI/CD pipeline.

Why do we need a full-stack developer? A simple answer could be that the developer can work on both backend API and UI components. Fair enough, they could be beneficial in the following scenarios:

• Small team — say 3 or 4 members max
• Enhancement projects where there is a budget constraint
• Support and maintenance project where the developer can pick a variety of tickets

But if you have more team members, full-stack developers at best would provide a neutral or negative effect. Wondering why?

The fundamental principle of a Service/API is Service Abstraction:

A service contract that contains details about what it encapsulates (e.g., the logic, implementation, and the technology used to build the service) may end up being used in a particular manner by providing the service consumer more knowledge about the working of the service.
Source: Wiki

Now, if you think about it, a full-stack developer doing an end-to-end implementation would easily get misled by his own actions and responsibilities. There will be several potholes in the codebase. The team will be able to discover them later.

Instead, engage a full-stack developer by tagging them with a UI or backend specialist and ask them to do the opposite role. Swap to a different role in subsequent sprints.

There are a couple of simple techniques which could decouple full-stack developers dependency from the development life cycle point of view:

1. API Contract
2. Mock Services

I would not be surprised if you think the above two points are trivial. Conversely, if you think these two points are time-consuming and nice to have, please note the following.

• API contract does not necessarily mean you should have OpenAPI / Swagger documents in uptight condition and published. It could simply be an agreement between API and UI developer on paper or over email.
• Adopting test-driven development (TDD) is the best thing for a project/product. But understanding and doing it correctly is not an easy task. Rather, start your development with mock services, which could eventually aid your unit tests and/or end-2-end tests.

React has 168k and Vue has 183k GitHub stars.
Mirage has 4k and MSW has 5k GitHub stars.
These data points show that the frontend development community has just started to adopt the test-driven approach.

Mirage (equally MSW) cuts down the dependency of the real API and fast-tracks the Web app development.

Don’t overboard the ORM feature of Mirage.

Conclusions

I am a full-stack developer and an architect myself. The idea of the blog is not to be prescriptive but to help you to recognize the possible pitfalls. I hope the ideas herein help your team. Feel free to let us know in the comments.

More content at plainenglish.io