I had heard about functional programming since Java made it available in 2014 with the release of version 1.8 of the JDK. I had been to several user group meetings where the speakers spoke glowingly of pure functional languages such as Scala and Haskell. It sounded promising, but I didn’t give it much thought until around 2018. That’s when I started seeing Java Streams being used more often in code examples. Recently, I was writing a simple integration solution, and the resulting code looked horrible. That’s when I gave functional programming an honest try. To my amazement, it indeed made my code cleaner. I’ll share my experiences with you and show you how you can make your code more readable with functional programming.
Spending time on software design is important because it helps you solve the big problems up front. Without this effort, developers can get bogged down, or worse, build something that doesn’t meet an important customer requirement. What you want to avoid is spending too much time in the design phase. After all, our objective is to deliver working software to our customer early and often. At some point we need to “get on with it”. The trick is to recognize that point
When do you know when to take a break from design and start building something? Well, one clue is when you find yourselves bouncing back and forth from one design option to another. Ask yourself, might this vacillating be due to a lack of information? If you’re speculating on what may be important to the customer, talk to them. Clarify what their needs are. Ask them what would exceed their expectations, and what would disappoint them.
If you have design options that would equally satisfy your customer, are you lacking some technical information? Specifically, how well do the capabilities of the technology stack support each of your design options? If this is the case, then it’s time to see what will work. Decide what metrics are important enough to help you decide on a design, then go and make a prototype. Take one of your design options, and build it out enough for you to benchmark it. Show it to your customer and get their feedback. Then take your other option, benchmark it, and get customer feedback. Repeat this for a
third option if you have it. Now you have some empirical data to help you with your decision.