Increase FE development throughput with UI first development

January 10, 2020

The Development Feedback Loop is a proven iterative process for developing new features and fixing hard-to-describe bugs. From a high-level, it follows:

1. Develop code based on a feature, user story, requirements, design assets
2. Deploy code changes to testing environment (i.e. Staging)
3. Collect feedback from stakeholders (i.e. new designs, scope revisions)
4. Repeat until complete

O( 2n )

From the frontend developer’s point of view, most feature code is split into two distinct components:

1. Smart / business logic
2. UI

Having common feature architecture such as this, we can estimate the number of times a component is rewritten. We can describe the upper limit of times components are rewritten, per feature, by borrowing Big-O notation:

For every feature, a FE team develops, the FE developers may rewrite components up to 2n times, when n is the number of feedback loop iterations.

For example, a whole team composed of Product, Design, Development, and BA’s complete a new feature together, after iterating four times in the feedback loop. The FE developers might have (re)written components eight times for this feature. That is up to four times rewriting a smart component, and up to four times rewriting an UI component.

If each component (re)write takes 1-3 hours, it will take 8-24 hours of developer time to complete the feature.

We can improve this, by refining what the team iterates on.

UI first Development

UI first development differs by leaving out the Smart component until the very end of the iterative cycle. This reduces the number of times the Smart component is (re)written to one. By leveraging documentation tools such as Docz or Storybook, team’s collaborate in a central location, while giving themselves a tool to increase the throughput, by reducing the amount of code developers have to write.

In UI first development, developers start by setting up a new UI component, once, inside the team’s documentation tool. It can look as simple as creating a Storybook story that returns a Logo component. This step can even be partially generated, depending on your setup (i.e. Nx).

Then the developers iterate on the UI component, first, inside the documentation tool, to deploy for feedback with all stakeholders. The team then can asynchronously visit the documentation tool, interact with it, to provide feedback in their own time, before ever getting into the weeds of the smart, business logic.

Once the UI is complete, the requirements for the Smart component are set, freeing developers to write the Smart component once.

Therefore, we can describe the upper limit of the number of times components are (re)written, per feature, using UI first development, as such:

One time to setup the Story or Docz markdown page (almost negligible). Then it’s n times of rewriting the UI component during the iterative Development Feedback Loop. Finally, it’s one time to write the Smart component for the set UI. That is where the time is saved, by reducing the potential number of times developers might rewrite the smart component(s).

Comparing 2n, n + 2

O( n + 2 ) is shorter than O( 2n ), except for when features are iterated upon, twice or less. Therefore, this process of development may not be worth the cost, for small projects, things just getting off the ground.

However, if the project will scale with multiple stakeholders, the iterative loop will grow, and in that, UI first development will save countless hours of developer time while providing valuable UI documentation.

Here’s a graph of UI first development (n + 2) and original development (2n):

_{*y-value represents the upper limit of component (re)writes for n iterations}

As you see here, the more complex the feature, the more exploratory the phase of development, the cheaper and more valuable it becomes, to iterate on the UI first, before starting on the business logic. Changes in the UI effect the requirements of the business logic.

For example, there is an User Story to build out a new Blog Post Viewer. This particular story ends up taking a team, four full iterations, to complete. The team’s PM goes back with design and marketing to consider the most important sorting features, to be included.

Originally, for each iteration, the frontend developers rewrite both Smart & UI components for this experimental Blog Post Viewer. To count the number of times developers work on components, we plug in the amount of times the team iterates on the feature:

Therefore, frontend developers have written component code up-to eight times, for this single feature.

This is opposed to the UI first development approach, where the developers iterate on the UI first, reducing the number of Smart component rewrites, to complete the feature:

By iterating only on the UI, the number of times frontend developers need to rewrite Smart components reduces!

How many features do you plan to deliver?

UI first development increases FE developer throughput by reducing the time it takes to iterate on complex features, while providing valuable UI documentation. But, perhaps most importantly of all, UI first development refines the focus of the team’s collaborative spirit, frees them up asynchronously, in building new features in a modern way.

It’s a technique to limit complexity during the iterative process of frontend development. When you limit complexity, you limit risk of failure.

If you’re interested in improving your team’s throughput, processes, architecture; reach out to schedule a Meet & Greet by emailing lage.michael@gmail.com with the subject, “Meet and Greet”. I’ll send you a scheduling link.