The concept of state in Scala and functional programming is an important one. Mutable state exposed from function and API calls must be understood and managed with defensive development strategies. Otherwise, development and testing resources will find their time taken up by side effects and other elusive defects as a result of scope misunderstanding or mismanagement.
In functional programming, much of the discussion centers on the concept of “state.” State is loosely defined as the internal representation of some programming construct which changes over time with respect to function inputs or calculations. In the case of mathematical functions, performing the same mathematical operations using the same inputs returns the same result every time. That type of function is considered immutable. Imagine the chaos that would arise if a function returned 10 for the sum of 3 + 7 one time it is called and a different value another time because of some state internal to the function. We would say that type of function has mutable state, which can cause undesirable “side effects.” Avoidance of state, where possible, is one of the prime goals when architecting and developing Scala code for any program.
In today’s digital economy programmers rely on various APIs to compose larger programs to solve business problems. These APIs can be public and open, like Twitter’s API, or private and internal to an organization. Powerful composition can be realized to create complex application functionality from more basic software solution building blocks through consumption of APIs. You might be asking what exactly this has to do with state.
Management of state turns out to be very important. If the API involves mutable state, the responsibility to interpret the return value falls to the calling application. Understanding the implications of state in code or APIs, corralling it, and coding defensively to handle it fall on the shoulders of the programmer. That means more effort not only in development, but greater scrutiny during the QA and UAT phases of an application. Because of mutable state, is the developer handling all of the possible return values? Do the test cases capture all of the possible conditions properly? Will an issue show up in UAT testing that was not revealed in internal Q testing because of incorrect state management?
There is yet another layer of complexity to consider. Today’s digital economy has made the availability of attractively priced cloud server resources easily accessible. All modern non-trivial applications have some multi-threading happening under the hood – various APIs are being consumed at different times, sometimes simultaneously. Mutable state with multi-threading across different servers causes even more work for the developer and tester. It becomes increasingly imperative to program defensively, using code constructs which can identify and handle the situation. If not done properly, subtle, elusive defects can be introduced in the application which can be almost impossible to recreate or catch during testing. Development and testing time increases, thereby increasing project cost and elongating the delivery timeline. All of these can be detrimental to competing in today’s digital economy.
Authored By: Dharmendra Kapadia, Senior Director, Solutioning, Ness Software Engineering Services (SES), US