Why should I choose functional paradigm?

Choosing a functional paradigm language has been a hot topic for a while. Functional vs. Object Oriented Paradigm is a constant discussion topic within the developers.

Before thinking the benefits of FP, the working environment must be suitable for modern work

The key of success at the management point of view is not to micromanage. Let the team choose their working methods and tools. The project is always a compromise between time, features and given resources. It’s all about how the project management sees that triangle.

Every tool and way to work has their own place. Telling the developers HOW to do work instead of WHAT to do is always a problem. It kills creativeness and get the authority outside the dev team. Too often the author is someone who doesn’t know about the actual developer work.

Treat the professional developers with this Sledge Hammer principle: “Trust me, I know what I’m doing”. Developers should know exactly how the program works, because code is the most detailed specification of the solution. It’s all about communication between the people – and between the human and the computer.

When the environment is suitable for working, then we can discuss about the benefits of FP

So why should I choose FP instead of OOP/imperative? What benefits it would bring the table? Here’s some thinking I’ve done in the past years based on my experiences:

Functional programming makes especially list handling a way easier. There are effective functional languages like Clojure or Scala. Another option is to use functional libraries like Ramda or Lodash. I like flexible code, so I prefer using scalable languages, like ES6, Scala, Java8 or C#/LINQ. With OOP and FP combined I have more options available. It’s also a safe choice when there ain’t so much pure functional programmers in the team (yet). Scaling the Object Oriented code with functional flavour is understandable compromise with functional averages like me. Actually I’m on my way of using only functional languages.

Here’s some benefits I found on functional paradigm which could save some money

It’s stateless and then also immutable, so no side effects

Object Oriented Paradigm is all about sharing the lifecycle between the objects. OOP makes problem solving often too complex, and complexity costs. Mutable state makes side effects possible, so code is harder to test with a full coverage. Developing with FP forces to code small functions. Simplified syntax (especially with pure FP languages) gives more time to think the actual business logic. Focusing on one thing at the time is clever.

When the state is immutable, it’s way easier to scale up and still control the whole

When programming high capacity systems, it’s crucial to design the software architecture to be scalable for parallel processing. If the program isn’t handling any state inside the runtime, it’s way easier to scale by using micro services or FaaS container platforms like AWS or Azure. Then the runtime isn’t blocked to serve only one client for a long time – there’s more time to handle many short tasks instead of a one big blocker.
So no more if-else-if-else or switch-case spagetti, or recursive for loop hell. Only function chains like map, filter or reduce one-liners.
It might be hard to transform the brain in the right mode after coding years with OOP. Functional code readability might cause many WTFs in the beginning, but – trust me – It’s worth of it. Like Twelve-factor manifest says “Execute the app as one or more stateless processes“. Start by one and try to write more if it feels right and suitable for the context.
Learning functional programming makes you a better OOP developer. You don’t have to be an expert, but it’s beneficial to learn something new. It’s hard at the beginning, but with the supportive team it’s possible to achieve.
Functional languages are simple by design when you let it be so.

Here’s a recap of my points:

  • Let the developers to choose the right tools and processes for building the high quality solution
  • As a team member, encourage the colleagues at least try to code with FP
  • Functional code is simple and easy to maintain. when it works, it works (no side-effects like in OOP). Broken code is easier to recognise and refactoring is less risky operation
  • Data must persist outside the code (like in Redux architecture). It shortens or eliminates debugging marathons. Less risk for wasting the time hunting the bugs from the production environment

See also:

How not to suck as an agile team member?

Do you think of agile development as an act of freestyling and cappuccino drinking with no plans attached? Let’s just do something and deliver it to the customer, they will surely appreciate it?

I have news for you: that could not be further from the truth. My experience says that agile team and agile team member needs two thing above everything else. Those things are discipline and communication. The latter is quite self explaining (I’ll come to that later) but discipline? Is that like waterfall?

Agile is about reacting to changes and delivering small deliverables often. And to be able to do that a team must have a structured process and agreed ways of working.

Let’s take for example DoD which stands for Definition of Done. DoD tells the team what are the conditions a requirement has to fullfill in order to be called “done”. Like unit tests and code review. What happens if somebody is not disciplined and didn’t write unit tests for a task? The rest of the team thinks that they are done! And yes, I do know that there are ways to make sure that no untested code get’s into master branch in version control. Another example could be a scrum board. What if a team member doesn’t update his/her progress in real time? The rest of the team doesn’t have a clue how the team is progressing. Discipline.

One attribute of a successful agile team is continuous improvement. Of their processes. It is impossible to have a perfect process in place from day one. And if you don’t improve you rot. Teams start with some process and work actively to improve it. One way to make improvement happen is to agree on an intermediate goal and actively work to reach it. Everybody in the team has to do their part. Discipline.

So discipline makes sure that the team is moving into right direction and the whole team is in the same boat. And communication is the way to make sure discipline is in place.

Serverless 101 and Siili CraftCon

The second official Siili CraftCon was held before summer holidays 2017. It is an internal craftmanship conference for all craftmen and -women in Siili. This time it was half days and three tracks worth of pure skillz with topics such as “how to be a tech lead“, “data driven design“, “RPA” and more.

I had the pleasure of speaking about serverless architecture to the whole crowd as a closing presentation. Since I am a keen agile/lean fan I am also totally in love in serverless architecture and everything it has to offer in terms of reacting to changes and feedback and the ease of implementing new features and trying out new things.

Serverless means that you only need to think of you business logic. Everything else is taken care of by your chosen vendor. All big name vendors have their own serverless platform and services. In this context I am talking about PaaS (Platform as a Service) and FaaS (Function as a Service) side of serverless.

Some may include SaaS and (m)BaaS solutions into serverless context. SaaS stands for Software as a Service and like the name implies it includes software you configure for your needs. Some examples are Google Apps, Dropbox and Slack. (m)BaaS is (mobile) Backend as a Service and it provides some backend services, such as authentication, mainly for mobile applications.

FaaS is a subset of PaaS and means you write your function in you chosen language (or in a language that is supported by your chosen vendor) and deploy it. You also have to configure how the function is called. It can listen to events or can be triggered by an http request via an API gateway among other ways. Your vendor takes care of scaling it to your needs and you pay only for execution time. Wikipedia explains FaaS as “A category of cloud computing services that provides a platform allowing customers to develop, run, and manage application functionalities without the complexity of building and maintaining the infrastructure“.

PaaS includes lot more than just FaaS. Widely available PaaS services include messaging, databases, big data, analytics, file storage etc. They all are services you launch and configure. You can insert your FaaS function in a PaaS workflow and use all other available services with it. Again your vendor takes care of your infrastructure needs like scaling and backups and you pay for what you use. Wikipedia explains PaaS as “A category of cloud computing services that provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure“. See how it differes from FaaS?

In short, serverless means you are responsible only for your code and your data.

In Siili we have a lot of internal serverless development also on top of all the fancy stuff we create for customer. We also have cloud sandboxes freely available for all Siilis for learning and trying out serverless stuff.

Thoughts about technology leadership

Nowadays we see the software development more like product development. It’s more common to work in teams instead of separate rooms alone (and communicating over tools). Today the team can really affect the working methods, tools etc. (like Agile Manifesto says).

Still there’s organisations who still prefer to use the old “traditional” way of managing top to bottom style, but assuming working agile. Strict processes might be recommended or required when we are dealing with for example life-critical systems.

If we look at the picture of Evolution of Management (above), it says that management and authority and trust is moving inside of teams. That’s a good direction because especially in software development the coders really have to know what to do to write the right business logic – so they have the actual authority to build the right solution which is based even more on Lean startup approach. There’s no responsibility handovers anymore – people are taking responsibility as a team, not based on roles or hierarchical levels – e.g. It’s not a designer’s responsibility to test  or code the system. Everyone must do everything they can to build a perfect solution regardless what the actual roles are – there’s only team of people, not team of roles.

About leading the people instead of commanding and controlling the resources and processes: it’s understandable hard to reborn as a leader instead of commander especially if the career has started in waterfall era. Nowadays managers are required to have a great social skills like empathy and flexibility. Today’s leadership in technology field is all about continuous improvement by making blockers or waste visible and focusing to removing them.

I see technology as a material like wood or metal. Technology can be crafted by developers. Somedays developers need to craft the tools of their own to do the things right, actually that’s pretty rare because there’s a pretty high level of standardisation of tech tools (for VCS or ALM).

The main focus of tech lead is to reduce the time between getting to know what to do and production installation:

Screen Shot 2017-09-07 at 9.54.32

Technology leadership is rarely evolved only in technology nowadays, because we have so much out-of-the-box tools or overall solutions for implementing the common scenarios, such as forms, wizards, web shops etc. It’s more about dealing within the team in social level (to enhance the team dynamics) – and at my point of view it’s definitely shouldn’t be related to technology at all. I see that the technology is going more high-end (naturally), but human-to-human communication should be in natural face-to-face form instead of communicating over tools. When interacting face-to-face, we have all senses in use, but if we work constantly remotely, it’s always harder to communicate over Skype – then you have only voice, maybe video, but there’s so much information you don’t see, and I see that harmful to team dynamics. It’s important to encourage the team to work as much face-to-face it’s possible – especially when the development is just started. It’s understandable not to strictly avoid remote work either – flexibility is one of the key assets of modern work culture.

Screen Shot 2017-09-07 at 9.56.36

Agile implementations like Scrum gives the framework to focus on the right things to answering the needs of rapidly changing world. As a tech lead it’s important to see also the social level as valuable as code – I mean how the team members support each other and really focus on the process and improving constantly.

There’s pretty effective principle for leading the tech team: If the product is broken in production, the problem is in the process – so fix the process to build the perfect product (actually it’s never perfect, or it shouldn’t be because of Kaizen).

Evolution of CI/CD pipeline

Back in the days there weren’t any tools for continuous integration or delivery (like Jenkins or Ansible etc). There was only ad-hoc build, manual testing and deployment done by developers from their own computers – and that was suprisingly ok (or they actually didn’t know the power of CI/CD tools yet). Actually it’s fine even today if we are looking CI/CD pipieline from a Lean perspective: to automate only the necessary parts of the value stream to get things done, BUT remembering to measure and improve the processes if needed (by creating a feedback loop and continuously measuring the process in retrospectives).

Sometimes it would be better to make your own tools instead of forcing to use ready made ones. I remember the times before Ansible when I was scripting a bit vague deployment pipeline with Powershell to deploy some PHP and Java artefacts to Windows environment alongside of .NET stuff packed into Nuget packages over TeamCity and Octopus Deploy. I know that was pretty questionable solution and I’m sure I’ll not do that again, but in the moment it felt a good enough (compromise) and I learned pretty much what it is to build things pretty much from the scratch. I found that a complex CI/CD processes could be an indicator of massive technical debt or cultural or process problems – but anyway, it was working and what was the most important thing. Customer got the solution and our team delivered a working software to production many times in a day.

Nowadays CI and CD pipelines can be presented as a code and stored to the VCS instead of managing configurations from the tool’s own GUI. Presenting configuration as a code is good because e.g. Ansible/Docker/Jenkins configurations are as valuable as the code of the main business logic and it’s fair to manage them over the same processes (for example pull requests, show-and-tell sessions , testing etc.). That approach turns the focus on the actual value and leads the change closer to DevOps culture.

Another good thing of modern CI is easier parallel processing set up. Today it’s possible to bring a flexible amount of Jenkins slaves in Docker containers if needed, or execute unit, integration and system tests in parallel by various tools like Gradle, Selenium Grid2 or Robot with pabot (for parallel end-to-end testing). Of course the cloud based CI services like Travis or CircleCI are pretty handy tools when project is suitable for using them.

But still the basic idea for me is to see the CI/CD pipeline as a part of the value stream. It’s all about choosing the right tools for the right case, or crafting the own tools if there’s no suitable one available.

More about configuration as a code: