Strong communication on engineering teams is crucial in order to efficiently build and ship quality, non-buggy code without friction. The need for strong communication grows even greater on eng teams where engineers are either FE-only or BE-only because, rather than a single full-stack engineer building the FE and BE of a feature, two separate engineers are individually building from each end of a bridge -- hoping that the bridge will connect once they meet in the middle. My last company hired only Full-Stack engineers and they were responsible for building features from the ground-up, FE and BE (yeah yeah, I know I just explained what everyone already knows). This made inter-squad communication more efficient as there were fewer parties partaking in conversation -- EX. A single FS Eng. is code-complete on a new feature consisting of FE and BE changes. The authoring eng moves the feature user-story ticket into "ready for testing" and assigns it to me, the QA. While testing the branch changes in dev, I find a bug with the new feature. I then file a defect sub-task ticket with details on the bug and assign the sub-task ticket to the authoring Full-Stack dev, at which time the dev and I talk about the bug to make sure we're on the same page. The dev fixes the defect and moves the defect sub-task ticket to "ready for testing" and I test it again to make sure the defect has been resolved. Then, after confirming the feature branch is working as expected, I approve the PR and make sure that all sub-tasks are complete and all pre-merge checks are complete before shipping the PR. All of this communication was between only two eng's, the QA and the authoring dev. Easy, low risk. Now, for segregated FE/BE eng teams, a single feature involves multiple devs to complete and thus exposes more risk for miscommunication and misalignment of acceptance criteria. My new company has FE-only and BE-only engineers rather than Full-stack engineers and we have a high-friction feature development process due to failed/misaligned communication. And it sucks. Bad. How do you overcome this? We have Jira and confluence and slack and yadda yadda yadda but communication is still an issue. Oh, and the eng team is fully-remote.
Agree upon the API first, then build out, or build the backend to fit the front end need.
tl;dr TDD This is primarily a failure of Agile. We should look for processes that allows communication to be asynchronous. The process should be primarily driven by docs and secondary by tests. The Swagger ecosystem contains many tools that let you do this. You draft out API specs that can automatically generate mock servers. You can write test cases while you draft the spec while getting (PR) feedback from FE. Only start implementation after the spec and tests are done.
Cross train until everyone is full stack
My current co is like this. Putting a note here for future reference. I’d love to know other’s experience too.