Efficient Fullstack Delivery

Many organisations face the issue of missed deadlines. The reasons for this might be a one-off case or repeated scenarios. Today, I’ll share how we’ve optimized full-stack product delivery through years of learning.

1. Clarity of thought - The leaders (product & engineering leads) involved in building a specific product should have a very clear thought on what we’re trying to build. If the product is in the very initial phase, this can be somewhat hazy. It is not a problem to “not have a well thought product”. But don’t let the hazy-ness propagate to development teams, otherwise, everyone will have their interpretation of the idea. Engineers are programmed mentally to work on exact requirements. The sense of ambiguity doesn’t let them work efficiently, at least in the initial years. To get the best output from them, give them clear requirements.

2. Get everyone on the same page - I don’t generally encourage meetings that involve many people, be it remote, or in person. Most of the things my team works on are communicated on JIRA tickets and clarified by chat, or short calls. But there’s a phase when you are starting on something new. The walkthrough of the initial idea should be done over a call (or in-person meeting if working from the office). This is the point when the product and design have almost finalized the workflows, the engineering leads have given a go-ahead on the feasibility of the product and the story is ready. Set up a meeting with the team, explain the idea, take their inputs, make the required changes (if any), see if everyone has clarity and then freeze the story.

3. Don’t exclude testers - In point 2, the “team” doesn’t mean only backend and frontend engineers. QAs are often shared across multiple product teams, so we think we’ll share the story with them once development is complete. This is an unoptimized process. We had been doing this in the past and it just brings confusion. Some of the issues that happen are:

   • Corner cases in product flows are not figured out initially as QA was not present in the initial meeting.

   • Some engineers might explain the product to the QA team in their own way when it comes to testing. The interpretation can be very different. Even if the product team explains the flow, it’s a waste of effort as they already did it initially.

   • Fixing corner cases might mean change in flows, design and hence code.

4. Walking on water and developing software from specifications are easy if both are frozen - This is a very famous quote in software engineering. Change is inevitable in software projects, and this doesn’t mean that our software shouldn’t expect future changes, but the point is that the current development cycle should have a fixed set of requirements. Product teams should have enough discussions with the required stakeholders to make sure that they are aware of what is “actually needed”. The cost of change in “software under development” is usually high - because the product team updates the story, design teams update their designs, developers change their code (often ending up adding hacks because they already built the previous version), QA needs to test all impacted areas, and the overall deadline shifts.

5. Estimations - There are two things we’ll discuss: Dev estimates and overall estimates. Assuming the designs are ready, the expectation is that developers should start working on the product right away. But don’t miss the estimation part, especially when you’re working with a new team. My team was doing PERT estimates in the past to do task breakdowns and estimate individual tasks. Once we have enough idea on our speed, we now share a ballpark (rough) estimate mostly. IMO, all freshers should learn to do PERT estimates. Apart from just estimates, it also helps you to break your tasks into subtasks. Once dev estimates are complete, the product team needs to take QA estimates as well, add some buffer (this comes from experience) and share overall estimates as a delivery date (Bonus point: Don’t forget to consider everyone’s leave plans at the start of development).

6. Realistic Parallelism and team motivation - 9 women cannot deliver a baby in a month. This phrase is used in software engineering to explain that we shouldn’t expect “faster delivery” just because we have the option to put more people. If your team is new, or the organisation itself is a startup, I’d always recommend starting with less people (or you’ll just be solving their conflicts). People management is a task in itself when you’re managing a development team that has multiple sub-teams. I remember, back in 2018 when I was developing APIs for our new mobile app, I was the only one from the backend team, 2 were from frontend, 1 QA and 1 Product guy. Even then we faced a lot of issues because none of us were experienced to work at that pace, and with less clarity. Our initial app took months to take off. Revised dates and unrealistic expectations of parallelism often affect the team’s motivation because leaders can’t see the needle moving and developers are expected to overwork for days (and sometimes weeks).

7. Technical perspective - Most of the above pointers are related to the overall team, so sharing some tips for the developers here:

   • Once the product discussion is complete, backend and frontend leads should connect separately to finalize the set of APIs.

   • Make sure that error codes and error responses are consistent and clearly understood by both parties. This is for the long term, not just for the current product.

   • Create separate sub-tasks for the backend and front end so that JIRA tracking is clear. The backend should start building models/APIs while the frontend should make designs.

   • If the backend needs some DevOps assistance to launch a new server, database or something similar, do include that in the estimates. Create task(s) for the infra team with the priority mentioned.

   • If backend development is expected to take much longer due to some initial setup of things, clarify the same. You might need to build some mock API responses so that the frontend team can integrate the same meanwhile. We have used this tool in the past for the same. If this is not possible, at least mention the exact API responses in your tickets so that the frontend team can write code against it and integration testing can be done later.

   • Don’t skip writing tests. No software system has been constructed in a way that remains unchanged in the future. Your manual testing effort is going to exponentially increase as more changes come.

Above insights are from my experience working on multiple full-stack products @ LocoNav, both for mobile and web clients. I’ve contributed both as a developer and as a manager, so I’ve seen the situation from both the lenses. If you think that your delivery dates are still shifting despite following best standards, consider doing a retrospective meeting after the delivery.

Take care and see you guys in the next post.