In part one of How to build a scalable frontend framework we looked at how important is the team effort when working on a project like RAIN. This article shows you the significance of having a solid understanding of your customer.
Understanding your customer
You have the team, now it’s time to have a solid understanding of your customer. You cannot sell your framework to everyone. It is essential to understand what problems your customers have. Split this into a set of features that your framework must, should, could, and won’t do. What the framework does is as important as what it doesn’t do. You have to be able to describe each feature in a phrase or two to someone who has none or limited technical skills, because you can’t implement it without resources that cost a lot.
Embark on developing
Once you acquired the knowledge about your customer, you embark on developing. The software business however is very volatile and there is always an external pressure to introduce changes. This in turn, increases the uncertainty and leads to “scope creep”. Remember to be agile. Even though lots of changes occur during the development process (new features appear, some features are dropped, others collide, the team changes), deadlines are set. The mission statement must remain unchanged: you know where you should go to, but you don’t know exactly all the routes. It is recommended to take it step by step. Do not think it over and don’t do premature optimizations because much of things will change. You must remember to collect feedback every step of the way. It is hard to have a considerable knowledge of problems from the very beginning.
Develop and do it right
Now, you develop, but do it right. Your customer won’t use your framework if it’s not properly documented, because he won’t know how. By developing tools you can make your framework usable for the client. Enforce the coding guidelines that the team agreed upon by doing code reviews. Test as much of the code as possible. The features grow fast in number, and so do the bugs. Involve the quality engineers into the development process. Quality and reliability will help you gain your customers’ confidence.
Scale
Once you have proven your design, start to scale. This will involve some changes, but you are already used to them and they will go faster this time. Every team member can contribute to every change because they aren’t specialized on some set of tasks. This is the current state of the RAIN framework. We started to scale and the design looks very promising.
What happens after that?
Improve performance, get more customers, write better documentation, develop more tools, scale some more and keep going forward.
