When functional programming is not a good choice
Functional programming is an incredibly intriguing coding model with both positive and negative sides. I’m not going to dive into details and describe how this paradigm works, I would like to tell you, based on my experience, how not to fall into the trap of becoming so interested in something that missing the main thing in product development, support the product.
Creation of a product, website or some kind of program is the main stage from design to MVP release, but this part is still initial. The main part is the support, addition, change and such a rarity as the removal of the code that will bring profit for several years.
The easier the code is to maintain, the easier and cheaper it is to develop the product. And it depends on the design, in other words, a small time interval at the very beginning allows you to create code that will allow you to develop the product faster in the long term.
It’s great when the company has an architect or a sufficient number of experienced people who, in a joint impulse, can create the right system but as often happens in small companies this opportunity is not always available. In this case, the developer makes a decision based on his experience and his views on the terms of reference.
5 or 6 years ago, I came across functional programming for the first time, because of my passion for learning and knowledge I could not get past such an interesting topic and spent many hours to understand how the paradigm works, what techniques exist and how to apply them and honestly admit it, it was not easy.
I used Haskell for a while to learn in my spare time, continuing to write javascript code for the company. And it was only a matter of time before these two ideas of javascript and FP became friends in my head so close that they began to penetrate into the workspace. As a result — hello Ramda, RxJS and very nice compositions in the code.
Once having received the task to develop and create a system for displaying information for the company’s partners, due to the passion of this paradigm, its application was the only option for the system. Having decided to combine the ideas of FP and frontend on ReactJS, as at that moment it seemed naively — a win-win. After all, FP is beautiful, clean and very interesting.
Indeed, I did not have any problems with the implementation of the system, adapting and implementing connecting models to ReactJS components through currying, and processing business logic through compositions. All this is perfectly connected and works with each other. Components draw pages, models store states, business logic is not scattered throughout the project, but lies in one place. Here are some examples, component implementation:
As you can see, props contain not only states, but also ready and-made events, which in their essence are compositions of an example of events compositions for one of the pages:
And also an example of processing business logic after the event composition has finished its work and called epic RXJS for ‘SET_NEW_PAYOUT_FIELD’:
And after all these years, this code and product continue to work and do everything that they have to do in order for the company to provide information to its partners. The main idea of such an FP implementation was to reduce duplicate functions and constant reuse of functions in the events and epics of RX, which in turn reduces the code base and makes it easier to test the code, add Ramda here and get even less volume that needs to be maintained.
Unfortunately, there is one fundamental detail here that does not allow us to say that the project would be optimal for the company. And I understood this detail already a year or two after the release of the product, this detail is called code support and everything connected with it.
Yes, I probably used 10%, or maybe less, when I created this system, from the FP capabilities, but this also led to not very happy consequences. FP is great, but difficult. First of all, it is difficult to understand, even if we do not use recursion, in order to read compositions we need to understand how the interaction takes place, what happens with the data and the documentation of libraries is sometimes not enough to solve even the simplest task.
I did not take into account the most important factor that not all people understand FP and not every developer has enough time to learn something new. As a result, in a small team, there were too few people ready to support the product and develop it due to the high entry threshold. And this is only half of the problem, the other is the speed of implementation of new changes, which in turn affects the implementation of new ideas to meet customer needs.
And this is a trap that I built for myself, created a system that within the company can be transferred to too few people to support the project, because they can cope with the task. Which forced me to support this product for a long time, even with other parallel systems in development, the development speed of which in this case always dropped, which affected the growth of the company.
Functional programming is not a good choice if the development team and the support team do not have enough skills and knowledge to make any changes within the system. This is relevant for any idea, and as the paradigm becomes more complex, the requirements for people involved in this product increase. If you do not have sufficient competence you are in trouble.
Summary
While working on a product, there are no ideal solutions so what techniques you did not use, do not forget that someone else will read your code and the clearer and more obvious each line is the more predictable deadlines. Carried away by some new technique, new framework or new idea, you need to be prepared for the fact that such an ideal road will not be as great as you thought.No matter how well you do your job, everything will depend on how many people want to walk it.
