How to go from Good to Great
This is an introduction to a multi-part series, where we explore making front-end development processes more efficient and scalable — to make a better product, faster.
Building a great product is often not a solo endeavour. The most elaborate setups would involve multi-teams of creative, marketing, product, and technology. Even if you’re a company of one, you will need to interact with your users, to gather their feedback about what works for them. This iterative framework of cyclical design process to help improve quality and function is commonly referred to as the Agile Iteration Workflow.
The faster you are able to iterate, the better your product would become.
At StashAway when the front-end team first started building the web-based product, we were on an accelerated timeline to launch, and our product development and management processes were less stringent. Now that the product is maturing, and as more features are explored and added, we are looking to enhance and tighten our process of building a better and more scalable front-end architecture for the product. Our current setup would not allow us to scale effectively in terms of feature offerings and country expansions.
To make a great product, we must perfect the iteration workflow. There are many product management literature on that, and that is not the scope of this series of articles. What we want to explore is how to be faster with iterations in the prototyping and building phase, and to do that, we will have to formalise our team’s internal processes of development and approval so that we can collaborate more efficiently with our creative and product teams. We think we can achieve that by making use of continuous integration and delivery flow in conjunction with the broader product iteration workflow as laid out earlier.
Ultimately, we aim to approach the declarative programming paradigm that expresses what we want to do in our applications, instead of imperatively coding the how. To do that, we will need to lay the groundwork of creating our building blocks.
We begin by expanding on our separation of concern with UI and application logic, so that UI components development becomes a separate activity. It will have its own central repository, together with common utilities, its own suite of unit, acceptance and regression tests. Our UI components will now be reusable, compose-able and theme-able, for variations of websites and web apps. When used with Storybook, we can create an interactive pattern library.
We will have the confidence that our UI components will look and behave exactly as it should so that we can focus on the fun and important stuff — the applications and how they should behave. We can apply the same process with our UI components to our application-specific projects, with more specific test suites to maximise coverage. It is only with these test suites that we can increase developer confidence in pushing and deploying code, and in return increase the speed of iteration.
With this central repository of compose-able components, we can prototype and hallway-user-test ideas, and even deliver new features at an increased pace.
You’ll have noticed that we’ve been hammering home the message that testing is important. Software testing is a vast topic in software development, but let’s focus on the four levels of testing integral in the smooth operation of continuous delivery process — unit, integration, system and acceptance.
We use unit tests to validate individual components, the smallest testable units, in a software. In our case, those are usually the UI components or utility helper methods. Integration testing happens when the individual components are tested as a group. For example, this could mean a feature such as a calculator, where you will have buttons and a display screen, and making sure the correct number is displayed in response to a button press. For API, an endpoint could make a database connection to retrieve a set of data.
Unit and integration testings usually weeds out most glaring bugs before we go into staging deployment. It saves time for internal and external testers, who will evaluate the completed and integrated system for compliance to feature and business requirements — domains of system and acceptance testing. Once the software passes the four levels of testing, we can deploy to production.
This is a sneak peek at how we are planning to make our front-end team’s processes more efficient. We will go into more details about implementations in subsequent posts about front-end development at StashAway. Stay tuned!
We are constantly on the lookout for great tech talent to join our team — visit our website to learn more and feel free to reach out to us!
