Scaling Full-Stack Team in 2023 (Spoiler Alert - Not By Size) - The Prestige (Part 3)

Note that everything written here is solely mine and it does not represent any of my past/present/future employers.

This three-part series will walk through my mini journey in search of a new holy grail for latest software development/delivery techniques

• Part 1 - The Pledge
• Part 2 - The Turn
• Part 3 - The Prestige (this post)

The Prestige

In this final part, I will be providing my thoughts on key actionable items that you can choose to mix and match to try to scale the performance of your team in 2023. Leave me a like and comment about your thoughts.

1. Employ User-Centric Driven Development

As an engineer in a full-stack team, your responsibility is end-to-end from maximizing user experience on user interface all the way to database indexing design for the best querying performance. The utmost desire to produce a winning product should pivot around what experience you want your users to receive. After you receive the product requirements from your product manager; be it a legacy format or User Story format (As someone, I want to achieve something), you could try to use the following steps instead of jumping in to write any technical specifications:

• Define boundary of user experiences with all possible negative scenarios, e.g. if the desired product behavior fails, this is what my user will get.
• Once the circle of experience is established, breakdown all positive scenarios based on the intention of product requirements.
• Use a consistent language of all negative and positive scenarios with Gherkin format (Given conditions, When something happens, Then users receive result). This allows conversations among your team and your stakeholders during analysis review to be more organized than using a random format.
• In modern day, most organizations have an objective to be inclusive and that means you must not forget to define the supported scenarios for both regular users and accessibility-assisted users.
• Depending on the style of your product manager, they would normally assume you know what you need to do for the product requirement on different screen sizes. Do not let that be a finger pointing situation or an excuse later that there is no explicit requirement about screen size support. Analyze the requirements and mockups and ensure to challenge your product managers and designers earlier in the cycle.

After this exercise is done, you can use it to drive the rest of system design, e.g. services, databases, observability, etc., as you normally would.

2. Emphasize On Component Driven Development

Whether you are working on frontend or backend, breaking down your implementation into smaller and manageable units never get old. Besides getting the required functionalities right, it is quite a norm to also follow some good practices such as S.O.L.I.D principles.

Specifically for frontend development, you may use Storybook to help your team build UI components and pages in isolation. This should help a lot with reducing complexity of frontend development due to the fact that it includes myriad of possible combinations that could make your UI go haywire including but not limited to color contrast, pixel-perfect positioning, states (hover, active, visible, disabled, etc.), screen readability, cross-browser consistency, keyboard navigation, and responsiveness.

The more the above possible scenarios are locked down at the component level, the less of chance things will go wrong at the page or feature level.

3. Leverage ChatGPT

I wonder who does not know about ChatGPT nowadays??!! It may be in its early day for software development support but you will miss the train if your team does not yet leverage it even with a free account. I wrote a very small post about using ChatGPT with my favorite IDE VSCode to explain how convenient to have ChatGPT as my buddy. You can use ChatGPT to help optimize some code blocks, write generic context-less code, and so on.

It of course will not give your team the best code ever but it surely can give your team codes that are above subpar (not every developer in a team is the most experienced or a superstar).

4. Invest In Fast & Rich Inner Loop

In the previous article where I summed up the lesson from one of the most respectable tech companies in the world; Lyft, regarding their evolution on scaling productivity. The best part it taught everyone in my opinion was to never forget about the fundamental testing 101; the team needs thick and rich layer of inner loop tests as the foundation for quality delivery and team scalability. No matter how fancy testing techniques out there you could find, think harder before violating the famous testing pyramid. I would suggest at least the following characteristics should be in your team's testing DNA (but obviously not limited to)

• Set your main objective to invest in fast and rich inner loop test portfolio where every team member can run that on every commit, push, or PR (whatever suits you best) so they can get a fast feedback if their change is breaking any existing scenarios.

• Optionally set your objective of such inner loop test portfolio to help onboarding members understand application expectations (if you make the log produced from your test in a readable way, e.g. use Gherkin to describe your test.)

• Employ techniques such as test double or mock so your team can shift left from relying on slow and expensive outer loop testing which may take hours or days to run into faster and cheaper inner loop testing which could be finished within minutes.

• Review the approaches being employed or used such as testing tools, testing techniques, process, etc. and ask yourself if you can keep up with this or how far we can keep up with this as the team grows technically and in size. Often you will see a pattern where someone produces something of great value and hope they can release and forget about it. This is not the case for maintainability, scalability and accountability. Put it simply, build something or come up with some process that is in everyone's regular routine (daily, weekly, monthly, or quarterly) so that it gets fixed when something is broken or it gets updated as the team evolves. Metaphorically, there is a part on my work-from-home table that I never have to clean built up dust; the part my arms rest on everyday. This can be learned from Lyft team where over the longer run, services built specifically on their OneBox environment were ignored because the owning team just focused on making them work on staging environment. Naturally selfishly if it is not one's problem, why one would care.

• Lastly specifically for frontend development, set your goal to cover business values within inner loop test portfolio as much as possible. I tend to believe every user experience where user can take action on your application is a business value (or why would you have that in the first place if there is no value?). It should be of best interest to protect against regression on such values. I could go further and say covering 100% user experience is more important than 100% code coverage.

5. Use Cumulative Flow Data

I am very opinionated against burndown or velocity metric that it is as useless as the story points making up of it. Use Cumulative Flow Diagram to give you insights into how the team is doing. Watch out for unusually long cycle time as it means something gets clogged in the delivery pipeline. Watch the queue size or work-in-progress as a leading indicator of potentially coming long cycle time build up.

6. Aim For Stable & Predictable Throughput

As I stated in my first part of this series; Quality is paramount. But time is sacrosanct. The best measurement of time in software development should not be the fastest takes all or should not be used in isolation. When pivoting that Quality should be the major side of the equation, Time measurement should be about stability and predictability. As time spent to finish something is in correlation with throughput, aiming for stable and predictable time everyone in the team spent to maximize the result of quality should be the major goal.

Thanks for reading until the end of the 3-part article. Whether you like or dislike, agree or disagree with any part, leave me a like or a comment and hope you get the best year of your team in 2023.