Speed up time to market delivery with the Functional Approach

After years of vigilantly adopting functional principles, we can finally declare that functional programming has reached the mainstream of day-to-day software development. Big tech companies such as Google, Microsoft, Uber and Facebook use functional programming daily to solve various problems – from highly specialised algorithms to get hot steaming pizza to your door on time, to simple looking tasks such as displaying the correct name of your friends when mentioning them on your Facebook status. Reasons such as “stronger safety”, “higher effectivity” or “more concise code” are well known already, but there is one topic we should talk more about, and which somehow seeps into all phases of any software project you can think of – complexity.

I am pretty sure you all know what complexity means and how to describe it. But there is one problem with complexity, especially in software development: There are many kinds of this beast and sometimes it is very difficult to distinguish between them. Let’s meet our enemy first and then we will talk how to knock it down with the mighty weapon called functional programming.

Essential complexity

I need to say upfront: you cannot beat this one! Essential complexity is something that lives with your software project all the time and it is impossible to get rid of. Essential complexity is as big as the business problem you are dealing with and it cannot be whittled down no matter how hard you try. If your business is about selling steel articles, you still need to understand the essentials of such domain as steel grades, EN norms, chemical compounds, firmness, or SI content. These define your core business and if you could somehow remove them from your vocabulary, your business would become meaningless. That is why this complexity is called essential.

Accidental complexity

On the other hand, accidental complexity is something you can, and definitely should, try to avoid. Many times, this kind of complexity is caused by misunderstanding of core business processes, poor communication within a team or by giving too much of weight to non-essential processes. And here I need to say that this kind of complexity is a coldblooded killer of successful projects. Have you heard those stories about developers being scared to touch old parts of code? Or how adding a new feature a competitor was able to provide within weeks, but which took your team half a year? And what about those developers who left a company because working on this project was “just too much?” You have? Then you’ve just met accidental complexity – your new biggest enemy.

How to tackle accidental complexity using functional programming

I’ll start with one thing that has nothing to do with functional (or any other kind of) programming but needs to be repeated over and over: Better communication. Try to shorten the distance between product owner and development team. Don’t be afraid to ask stupid questions. Ask “why?” Do not be afraid to confess that you don’t understand. And do not be afraid to disagree or object. You can adapt the best functional concepts having the best development team, but if your communication is not smooth and clear, you will not achieve success in a long term.

Now we can go on to functional programming concepts. I would strongly recommend starting with this one: Think immutable. O.K., it sounds weird, doesn’t it? Let me explain. Whenever your software makes some kind of change (like updating a person’s first name from “John” to “Peter”) you can do it in at least two ways. You can really update the record directly and change the first name as you would do in good old days. Or you can create a new version of the record, now having “Peter” as the first name. Why would you do that? First of all, the second – immutable – approach is not destructive. You’ve created a new record based on an existing one with some things changed, but you did not touch (or mutate) the original one. Another benefit is that you now have a full history of changes. Do you need to track how a person’s record changed over time? You already have it! And something else you are going to love – the trust. If you know that the whole codebase is immutable, you don’t have to fear sending your precious values as parameters to any function – it will be never changed! This level of confidence is unbeatable and very addictive. If you ever lent your favourite Beastie Boys mixtape to a best friend and got it back overwritten with New Kids on The Block, you know what I’m talking about! (90’s kids will understand). Did I mention that immutable code is also way less complex thanks to the fact that many complexity boosters such as locks are completely useless?

Another thing you’ll love about functional programming is…

Well O.K., I’ll stop here. You don’t want me to spoil all the cool stuff from the next CN Group Webinar, do you? Join me and Oliver Schmukala talking about complexity, successful software projects and functional programming concepts on 23rd of February. Looking forward to it!