DEV Community: Chakrit Nimmanant

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

Chakrit Nimmanant — Wed, 08 Mar 2023 03:08:23 +0000

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.

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

Chakrit Nimmanant — Wed, 08 Mar 2023 03:08:15 +0000

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 (this post)
Part 3 - The Prestige

The Turn

As mentioned in Part 1, my search of a new holy grail for latest software development/delivery techniques led me to 2 sources that inspired me about Quality and Time.

Quality

Let's talk about the first source which is a four-part article written by Lyft Engineering Team about their evolution on scaling productivity.

At first Lyft was approaching their testing process and environments like what everyone else would and as if we were all a by-product of the same school of thoughts. The environments were set up as follows:

Devbox - An in-house local development VM that took care of everything starting from packages installation and update, configuration all the way to database creation and seeding. The only thing left to be done for a developer was just a command to start it up. How convenient!
Onebox - A longer-lived environment which can be shared within the organization. It is basically Devbox on steroid running on high-tier EC2 instance (r3.4xlarge).
Staging - An environment that is nearly identical to production except it has smaller footprint and no production data.

And this is how the testing process looked like

Local test - Lyft team relied on Devbox to conduct local testing across multiple services on their MacBook laptop.
Integration test - This test is conducted on Onebox's cloud infrastructure. A manifest.yaml file would define the group of dependencies and a temporary Onebox would be spun up to execute tests per each pull request.
Load test - The staging environment is used to perform load testing. The decision was the result of the surge in rideshare traffic during peak holiday events such as New Years Eve or Halloween. Lyft built a simulation of ride traffic at scale to run against the staging environment and it constantly generated up-to-date data for users, rides, payments, and so on. The deploy authors would see error logs and alarms immediately if anything goes wrong.

The above environments and testing process seem to be so perfect out of textbook. What could go wrong with that design coming out of one of the best group of software engineers in the world?! This seemed like the best setup you could wish for as a software engineer if you wanted to aim so high for a top-quality product. Let's find out more below.

Scalability - Eventually as Lyft's services grew so large that it was impossible to get Onebox to be useful as it was used to be. People probably got upset before giving up and moved to testing in Staging instead because it scaled so well. However, as more engineers flocked into relying more and more on Staging, they made their own disservice because some changes broke Staging blocking others from completing their work. Also since one change per service could effectively be tested at a time, it took merely too long to build, deploy and get to your turn for testing.
Maintainability - With the growth of Lyft's services which indirectly enticed people to ignore Devbox and Onebox in favor of Staging for their testing (also at the same time, Production and Staging were well-maintained), the boxes were falling behind more and more. As a result, less teams were taking care of how their services behaved in Devbox and Onebox triggering downward spiral of maintainability.
Accountability - Given the aforementioned of Onebox's status, there lacked a clear ownership or accountability of who should fix what when something breaks.
Efficiency - If you're a seasoned software engineer, it is not beyond fathomable to predict that more often than not, the response to defects or production incidents would involve adding more testing coverage on the environment that you would trust to catch the regression; yes.. the Staging. This in a way caused the entire test suites to be bloated and full of obsoleted test cases because, you know it, we only tend to add rather than remove; it's generally saver of course.

After I read up to this point in the first part of the series, it just dawned to me - here in a metaphorically fashion - that we often have a good intention to plant one tree at a time but forget how the forest shapes up until it's a little too late.

Quality is never the only mandate and time, in whatever dimension to be measured, has to be accounted for. I will not go any deeper into the rest of Lyft's series as you can follow the original article and read them yourself. What I learned from Lyft's transformation though is very powerful yet people always forget to refer back to Software Testing 101. Sticking to the testing pyramid and making it to work for the best of your software's quality and time.

Time

Alright, now we got most background about Quality and Time spent during development cycle. How about the other side of Time that we, professional software developers, would worry about; Time to release or how much a team really delivers in a given time.

In Agile development, there is a guideline of velocity measurement where it is assumed over the long term, an Agile team should be able to build a baseline of story points that they are capable of. In addition, the baseline will be used to predict how much the team can deliver in a sprint or even the entire project. This property of story point has been advised as a way to measure productivity. Please do not get me wrong, I believe I understand enough about a lot of misconception on story points such as that it is bad when delivered points are down in a given sprint and some teams would pressure themselves to get it back up. Leave me in the comment below if you believe I get it incorrect otherwise.

Having been working in so-claimed Agile environment for almost a decade, I am yet to satisfy about any of my past experience on how exactly I should measure whether the team is doing on its own best about time spent to build and release value. In many occasions, I often have a big doubt about the flakiness of story points starting from how they are assigned, poker-pointed and to eventually how they are being really useful over the long term.

This unsatisfactory brought me to do more research for a practice that may or may not be already out there somewhere in hope to find an answer that I will feel better than what I have had experience with - as harsh as I could be, story point concept has been useless to me in practicality. Then the search brought me to the second source of my inspiration about Time on a podcast featuring a blog owner named Lucas F. Costa. You could go follow Lucas's blog here.

In one of Lucas's article, he laid the groundwork resonating with my experience velocity is not an effective way for engineers and managers to use as metrics because it in and of itself does not give readers enough insights to conduct an effective data-driven team conversation. On the other hand, Lucas proposed to look at the software delivery pipeline as a queue where the following properties are more useful as metrics:

Arrival Rate - The rate at which tasks arrive in the system
Departure Rate or Throughput - The rate at which tasks leave the system
Queue Size - Amount of work in progress at any given time
Cycle Time - Duration a task gets done

Those properties in modern software development tools could be shown under "Cumulative Flow Diagram" as shown in the image below (Image reference: Lucas's article)

In theory, the textbook CFD will look like below where it indicates your engineering team is having a constant value delivery pipeline, e.g. stable throughput. Images below are borrowed from the article.

However, one of the examples I love the most is below where Lucas demonstrated a situation where the engineering team might have an issue with accumulating some tasks for too long resulting in multiple periods of no throughput.

At this point, our readers may ask further if there is anything you could do to prevent some undesirable to happen, you will not be disappointed that Lucas also outlined his rationale in another article. It comes down to avoiding a fundamental mistake that most of us seasoned software development professionals know but may forget from time to time; High Capacity Utilization. In short, watch and control the queue size which is a leading indicator of arrival-throughput imbalance; hence long cycle time which should be avoided. The concept of watching out the queue makes total sense to me where if your team can only work on 5 units of task at any given time, the more items in the queue means the more pressure your team will feel and it would seem everything is a priority and a rush. What do you think about this so far, leave me a comment below.

I am not sure how much you are convinced so far with Lucas's work but let me assume that you believe to a degree that large queue size is a leading indicator to long cycle time which is a bad thing. But what exactly why it is a bad thing?!?!

Hear me out, I cannot say I believe everything Lucas said but to this question, he has another article that explained what long cycle time tends to produce here. In essence, long cycle time kills productivity due to possible incurring overheads such as context switching costs, accumulated delta changes, difficulties to find defects, etc.

After I read all Lucas's works up to this point, I have my own conclusion that

The best measurement of Time in software development is not about Speed but Predictability

This is because to be predict something, the following elements must exist:

Stability - If something is stable or consistent, the metrics against that can be used to predict more accurately
Scope - Aiming for predictability encourages us to break down our works into small meaningful units where we know their boundaries

Still not convinced? Let me try one more time. In the same article, Lucas used Monte Carlo mathematical model against 2 hypothetical team where one is having a consistent throughput (small and consistent batch deliveries) while the other team is the opposite (large batch deliveries). The simulation result on the team with consistent throughput yields a smaller possible ranges of the number of dates needed for the entire project (from around 20 days to 40 days).

On the other hand, the team with high variability of throughput data results in wider range of possible project duration (from 0 days to 90 days)

My last word - what customers would not love a company that keeps their promise of product specification and deadline?

In the last part of this series; The Prestige, I will combine the lesson from the two great sources above into my thoughts on what I believe is one of the best ways in 2023 to support your team to scale and thrive in the new economic expectations through the definition we just discovered about Quality and Time.

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

Chakrit Nimmanant — Wed, 08 Mar 2023 03:07:55 +0000

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 (this post)
Part 2 - The Turn
Part 3 - The Prestige

The Pledge

It is roughly 2 months into 2023 and I have been thinking about summing up what I learned since last year about my journey embarked in search of a newer holy grail for latest software development/delivery techniques out there. My context is what's suitable for a full-stack bite-sized squad of 7-10 engineers.

My criteria is quite simple; how to support such team to constantly produce a series of winning products, releases or feature in the new economic environment.

Metaphorically, if the US Federal Reserve's dual mandate is maximum employment and price stability, my search sure comes with one.

Maximum Quality and Optimized Time.

Unlike the past decade of free money with low interest rate and growth-first-cash-flow-later, nowadays investors are looking for more return (cash flow). The principles to producing winning products from engineering perspective in this era should also adapt. Actually it should have always been the case but the past decade might have enticed different behaviors.

As a matter of fact, when I first thought about quality and time, they're usually on the opposite end for the fact that more often than not, more time is required for better quality and vice versa. There is another quote popping in my head about 4 years ago that seems to better describe the relationship between the two when it comes to software development.

Quality is paramount. But Time is sacrosanct.

I was inspired by a remarkable dialogue between two persons on a Netflix series Frankenstein Chronicles and it goes as

A man's rights are paramount. But a gentleman's rights are sacrosanct.

By the way, if you're a fan of fiction series like me and have not watched The Frankenstein Chronicles on Netflix (It's from 2017 so it may already be taken down), I truly enjoy this type of period crime and it is fun to watch.

Out of a lot of reading and searching, I found 2 sources to my inspiration for this article that also got me reshaping my perspective about Quality and Time.

The first is a series of article from Lyft Engineering (you can start with the first part here and continue to the rest of the series from there. In this series, a group of Lyft Engineering teams shared their learning from the early day until 2018 where Lyft grew from 100 engineers to 1000+ engineers and how they attained maximum quality as well as optimized time with different approach to testing paradigm. The key takeaway for me is predominantly the paradigm shift of the importance and roles of local testing, integration testing and production testing.

The second is a set of articles by Lucas F. Costa; Engineering Metrics, Finish What You Start, and Measure Queues Not Cycle Time. I ran into his name from listening to a podcast which at the time got me really excited that eventually somebody provided me a very convincing case that Time in the context of software development in general or even in Agile principles is not about being the fastest that always matters.

In my next article of this series - The Turn, I will walk you through what's my learning and how I came up with a set of practices I believe is the best way to scale a full-stack team in 2023.

Even if you're a professional software developer, don't miss out on CodeGPT + VSCode

Chakrit Nimmanant — Sun, 12 Feb 2023 19:46:45 +0000

As a professional software developer, you're likely familiar with VSCode - one of the most popular and versatile code editors in the industry. But have you tried using the CodeGPT extension to enhance your coding experience? If not, you're missing out on some serious time-saving and productivity-boosting features. Here are some tips to help you get started:

1. Understand what CodeGPT does

CodeGPT is an extension for VSCode that uses OpenAI's GPT (Generative Pre-trained Transformer) language model to provide auto-completion and code generation suggestions. In simpler terms, it can help you write code faster and more accurately by suggesting code snippets based on what you've already written or what you're currently typing. It's like having a coding assistant at your fingertips.

2. Install and set up CodeGPT

Installing CodeGPT is easy - just search for it in the VSCode extensions marketplace and click "install". Once you've installed it, you'll need to sign up for an OpenAI API key and configure it in the extension settings. Don't worry, it's a quick and painless process.

3. Learn the keyboard shortcuts

CodeGPT is designed to be as unobtrusive as possible, so you'll need to learn a few keyboard shortcuts to take advantage of its features. Here are some of the most useful ones:

ctrl+shift+space - activate CodeGPT and display code generation suggestions
ctrl+space - display auto-completion suggestions based on what you've already written
tab - accept a suggestion and insert it into your code
esc - dismiss the suggestion window

4. Customize the settings

CodeGPT comes with a variety of settings that you can tweak to suit your coding style and preferences. For example, you can choose whether to display function arguments in the suggestion window, or whether to use camelCase or snake_case for variable names. Take some time to explore the settings and experiment with different configurations.

5. Practice, practice, practice

Like any tool, CodeGPT requires some practice to get the most out of it. Start by using it for simple tasks, such as writing boilerplate code or filling in repetitive sections. As you become more familiar with its capabilities, you can start using it for more complex tasks, such as refactoring code or implementing algorithms. With practice, you'll soon find that CodeGPT is an indispensable part of your coding workflow.

Still not convinced? Below is just one of the many very simple examples a developer might run into while doing code review or coding something perhaps while feeling exhausted from long hour works and not being oneself.

What a bad code may look like

Here is what I get from CodeGPT by asking it to help refactor for me. Not only does it reformat into something I feel better with, but also explains what are not so good to have in the first place.

In conclusion, CodeGPT is a powerful extension that can help professional software developers write code faster and more accurately. By following these tips, you'll be able to take full advantage of its features and become a more productive coder. Happy coding!