4 mistakes in scaling long-running product and how to fix them
In this article, I will discuss our experience with building and delivering new core functionality into long-running products. It relates to cases when a product is live already with one key feature and the team’s goal is to develop MVP of one more new core feature and make the integration process smooth. The following are 4 mistakes and I am offering possible solutions to each one.
1. Neglecting the analysis of the current technical background
The problem is that the current version of the product is not technically prepared for scaling. Talking from our experience, some of our backend services were in the middle of transition to clean architecture using a new programming language. New functionality implementation was expected to use new technology stack, but possible communication between new code and not yet transited services was not taken into account. This caused unplanned refactoring of old services on the fly. Another challenge was complicated DB migration. To make it smooth and safe, the version of the database management system needed a severe upgrade.
Possible solution: Take time for deep analysis of current product technical state and initial investigation of upcoming changes. The goal is to specify what services could be affected by the development of new functionality, what data format will be used, how difficult it is to migrate data and code now, if any technical improvements are needed before implementation starts. Moreover, you should convey information to the client - describe benefits of making technical preparation first and cover the needed time and human resources in advance.
2. Skipping stage of analyzing 3rd party services API before user stories refinement
This problem mostly happens when 3rd party services have poor documentation, and developers need to play with external API and try to guess how it works.There could have been some limitations or a required functionality may be missing. These can lead to global solution re-thinking, changing user stories and some re-designing work as a result. This process is expensive.
Possible solution: request 3rd party services to create and provide clear API documentation in advance or set up a session of meetings to get all questions resolved. Do not guess how it works but wait for explanations. It is better to concentrate on your end code that you have a clear vision about. Do not start with the design until you have all technical limitations resolved.
3. No clear communication between frontend and backend team
In our case, backend work was started much earlier than frontend. The API was re-written and extended several times later because of different understanding of how some functionality is expected to work on API level and design changes.
Possible solution: Take time to discuss and document data formats and new APIs that the frontend will need to cover design requirements during early development stages. Set up regular dev-sync for step by step progress review. If possible, both frontend and backend should be synced to be working on the same set of features (even if one party is ahead of another).
4. Overthinking.
Since the product launched a long time ago, the team knows a huge number of edge cases and things that could confuse users. These cases were resolved/improved during long time support of the first core product feature. During our refinement sessions based on team experience, most of such cases were anticipated and covered for new functionality before the first release. Every single edge case was important for us. And as result this had a big impact on the original scope.
Possible solution: Decomposite initial requirements as much as possible. Investigate and discuss cases that were not covered with initial requirements. Define, limit, and prioritize the set of requirements for the first release, considering the deadline. Deliver, get feedback, and improve. Create scope of future enhancements to be delivered in future releases.
These points above are things that we learned from our experience. I don’t want to overcomplicate the process, but I found it helpful to know this before starting implementation of new complex features and integrating them into a live product. It’s hard and requires a lot of communication with the Product Manager to challenge every additional requirement, protect the scope, prepare a product for scaling, and ensure your new feature only includes things that are possible to implement.
Setup prerender on webpack with prerender-spa-plugin, Part 1
During developing SPA (Single Page Application) we met with a common SPA problem: although google crawler uses the last Chromium version to run JS and indexing results as HTML pages (it’s not so easy to make it work and there is still the Fix Search-related JavaScript problems list), but for other search systems and sharing in social networks SPA doesn’t work. They will get the default index.html with the default title, description, etc for all pages.
Building An SVG Map With Vue.js
This article provides a simple example of using Vue.js to work with SVG graphics.
Handle million requests per second during rush hours
For end-user, it doesn't matter how powerful your server if user needs to wait for couple seconds the see content on the main page. We are talking about latency of the whole platform in general and you need to keep in mind that a system is only as fast as the slowest component.