Every engineer faces the complexity of development and delivery of large projects or features. Through the learning process and experience gaining, we find ways how to tackle those problems.
In this post, I’ll share with you my own experience on this question. Get ready, we are starting now!🔥

Photo by Jon Tyson via Unsplash

No understanding — no happiness

Before I will start the development I have to understand the project. Engineer can’t solve a problem if there is no understanding of it. This is why it’s crucial to understand what problem are we solving. Sometimes it takes some time, and that’s fine.

Once I do understand it, I can make the next step, and start the planning process. This is a perfect time to start the implementation details discussions and do the initial estimation of the required amount of work.

Usually, complex features require both frontend and backend work. This is why we should avoid the situations when frontend development is blocked due to not ready API.
To solve this problem engineers should start the API design process as soon as possible, however, the backend can be implemented any time in the future without blocking the frontend. And here is how.

The API can be designed and documented without immediate implementation. I recommend using the API Blueprint Format for it.
In this case, once we have a ready-to-go API documentation, the FE can easily implement this API using a mock web server which responses with mock data, but with correct response format. In this way the frontend development is completely unblocked from the backend and can be implemented even in front of backend.

Smart delivery process

The next pillar is a delivery process.

Imagine you are working on the large project. The estimation is around a month of full-time work. Typically, people do not release anything until it’s done. And done usually is far beyond the original estimation. This situation is very bad, and this is why. The company (team) spent a huge amount of time and money for a project and they don’t even know yet if customers will use it!
Receiving feedback is essential. The sooner project can be shown to others is better.

How can we avoid this situation? The answer is very easy. Validate your ideas as soon as possible. Get the feedback from users on early stages. Build the MVP and show them what are you working on.

What about engineers?

Through the developer’s prism, this approach can be applied as delivery of the feature by chunks. Avoiding super large and stale PRs will help you better structure your code and organize your job. But it will also simplify PR reviews for your colleagues. Just think through the feature, and split it into several development phases.
This is a win-win approach because you’ll deliver something working much faster, your product team and customers will be able to give you instant feedback.

Quick validation of product features is a vital process which helps the company to stay ahead of competitors. This is why it is related to everyone involved in product development.