This article started as an internal document for Fluxon’s worldwide engineering team to aid in onboarding engineers with new projects. These principles reflect our experience in working in lean environments over 80+ client projects, and they help us to be more efficient by making the work of our engineering team more frictionless.

What is a “lean software environment?”

Lean software development describes the approach to developing software as a product that originates from the agile development community. It was created as an alternative to the waterfall model of development and describes an approach to software engineering that results in minimal waste, individual empowerment, and fast iteration cycles. The idea of a lean environment is a similar concept that retains similar ideas, such as delivering quickly and deferring unnecessary decisions. While the team can be compact and ready for lean style interaction, the engineering approach is often still tailored to the waterfall model. Instead, there are some key practices to keep in mind while coding that are better suited to lean software development. 

Let’s look at the product lifecycle from the perspective of a sole front-end engineer. Code is written in somewhat of a waterfall approach in that the design and API requirements are passed down from upstream. It is much easier to write code having these all aspects of the product agreed upon in advance, but in reality, that rarely happens in startups.

In early product development there is uncertainty at every stage. Early front-end products are a screen or a set of screens to address a specific user flow. The beginning of a product is primarily an aspiration and there’s no complete product specification to pass down. The design doesn’t start with a design system; it starts with solving a very specific user problem or need.

Later on, the product evolves, but evolution isn’t simply adding screens and functionality on top of the existing ones. Changes come to all parts of the product: to existing screens, to the functionality, the API, the initial user flow, or even the entire navigation, look, and feel of the product. It is not uncommon to have a design agency perform a branding redesign before introducing the product to a general audience, and the front-end’s appearance will need to be adjusted accordingly.

Accepting uncertainty

This might sound like a hostile environment to a proper front-end development, but that’s only the case if you are expecting a waterfall process. Alternatively, let’s think about how to align development in order to achieve a better and more efficient development experience that also frequently creates better products and outcomes for both the users and company.

First, accept that all parts of the product are subject to change. The amount of change isn’t boolean, but rather on a scale, so consider how much each part can change. Basic components like buttons are going to change their design, entire screens and sections of the application may change, and the product’s overall vision will inevitably evolve while the product is being developed.

By accepting that changes will happen, you don’t need to make assumptions as to how the project will develop. In terms of source code, code structure should be written as “good enough for now” so it retains flexibility while still being high-quality. My personal code quality metric is this: code is good if it can be deleted easily without affecting much of the codebase.

Software engineers are often taught that duplicate code is bad, and many of us have a natural tendency to want to build frameworks. The reality is that a little code duplication is fine and even necessary to deliver quickly. For example, start extracting your front-end components from the layout only when the same component is present in the codebase three or more times.

To exemplify that agile practice of amplifying learning, make sure to co-locate code as much as possible. On the front-end, both layout and styles should be in the same place, as these are changed frequently. For example: don’t try to create ten small individual component files for a single larger page that are used only in a single place, since this produces code that is more difficult to change and maintain.

”First, accept that all parts of the product are subject to change. The amount of change isn’t boolean, but rather on a scale, so consider how much each part can change. Basic components like buttons are going to change their design, entire screens and sections of the application may change, and the product’s overall vision will inevitably evolve while the product is being developed.”

A lean approach doesn’t work for every project

There are certain kinds of projects where this kind of lean environment approach is not the best option. For example, large enterprises have much longer development and release cycles, because there is more risk to rapid product changes and more teams need to collaborate together in order to align on requirements. As a result, requirements are often much more defined and longer-term before they are handed to development. Companies or startups that have gained a larger user base typically also have slower cycles, so changes are likewise not going to be as frequent and code can be structured more strictly for more efficient development.

Notably, I would also not advocate a lean environment for projects where the codebase itself is a product which is consumed by other engineers, such as company-wide design systems or libraries for general use. The approach on development for these projects is completely different since the type of end consumer has different needs and preferences from your average front-end user.

A lean environment helps early startups

The approach presented here is more than engineers having the right expectations for product development or having the right attitude towards code. A lean environment also reduces waste, such as overengineering on features of apps that may be not released at all. It allows teams to be more flexible, to accept feedback more freely, and to maintain the versatility that lets them change functionality more frequently and swiftly build an increasingly better product for users.

There is no “does it scale” problem for frontend development

One advantage of front-end development is that there’s very little concern for scale, other than making sure that users’ browsers can keep up with large amounts of data. Startups are often built with scaling in mind which requires careful architecture of the backend. There’s no such issue for the front-end because the front-end scales horizontally naturally, since each client has its own instance.

These are general principles applicable to front-end development in a lean environment. In later articles, we will introduce specific recommendations we have on tools and project structure that implement these principles. Stay tuned!