How to handle interface change between back-end and front-end during development

Question

Introduction

In our development team, we divide developers into back-end and front-end teams. To develop a feature for a website, the 2 teams have to work in parallel. We starts by analyzing the requirement, talk about all possible business cases that should be handled, and have agreement on APIs interface specification that regards the solution for all cases. The back-end team then build the mock version of the APIs according to the specs (using Spring Boot). The front-end uses the mock APIs to develop the UI (using VueJs).

During the development, when the developers focus deeply into the real code, they always find more business cases that the team has never talked about. Meetings are arranged to discussed about this, and often the API interface specification will have to be changed. The developers always have to rework, and the project is delayed.

This problem reoccurs everytime in our development cycles. The management challenges us to find a solution so that all the business cases have been considered during specification design and no cases should be popped up during implementation that affects the specification.

As a developer, I list the cases as much as I can think in the design phase, but they are never completely covered all the cases. Only way I can discover the missing cases is to write the code.

Question

Is it common (and okay) to have specification change during implementation phases?

If so, how do you handle the change to minimize the impact that causes project to delay?

If not, could you please suggest what might be wrong for development process in general that obstructs development team to have clear and complete specification before implementing.

Answer 1

You need to redesign how you approach your development. You have an application team, not front and back teams. These people need to work together and collaborate all the time. They should be co-located for better collaboration, or have appropriate remote communication tools. Changes should be expected as you develop, most software projects have massive unknowns, you adapt to this by adopting processes that make changing things as easy as possible.

If you have a story to add a new Foo detail screen in a sprint, assign front end Jack and Back end Jill to the story and let them create a rough draft of an API in about 15 minutes and let them develop from there. Then if Jack discovers that foo details sometimes have special property X that wasn't in the initial spec, or if Jill discovers they need some Bar details, then they talk to each other and redefine the API spec as needed. Then when they are both confident development finished write up the final version of the API if you really need that documentation. Another important thing is to integrate changes as early and frequently as possible, because you will start uncovering issues faster as well.

Separate teams all designing to a spec only works if the spec being designed to is perfect. I'm willing to bet that in your current set up the time between when the first person finds a problem with the spec to the time when all teams agree on a solution is measured in days, that puts you behind very quickly. Then, you have a team spending time developing against a known bad spec, which puts things further behind while they believe they are progressing. The more integrated your teams become, you can get that time between identifying a problem and having a solution down to hours or minutes.