What would be good factual arguments to convince high level management to consider functional programming? [closed]

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/267881

Question

There are tons of "theoretical" arguments for why functional programming is a Good idea (too many for that to have stayed as an open question, and correctly so).

However, most of them are arguments either made from theory ("elegance", etc...), or, aimed at developers.

The problem is, most of them are entirely useless when one's goal is to present the idea to senior management of a large company, some of whom aren't even developers, and all of whom mostly care about business arguments: cost, human capital management, product delivery, client service and revenue; as well as quantitative facts over theoretical points that can't quite be backed up with facts.

Are there any compelling arguments to present to address those business concerns as far as considering adoption of functional programming as a concept (not any specific language), vs. the typical mix of procedural/OOP, e.g. Java/C++/(Perl|Python).

Preferably, I am looking for arguments that are quantitative and/or based on research or case studies. E.g. "according to this reference, the bug rate of multithreaded systems in Lisp/F# is 10% that of Java" or "80% of top graduates expressing preferences of desired technology named functional programing as on of top 3 interests".

I know that Graham presented use cases of functional programming for a starup and would be open to some of his arguments assuming they can be valid for a larger established company.

p.s.I'm perfectly aware that you can do something close to functional programming in Perl, likely Python, and (possibly) even Java 8 or C++ 14. But that doesn't mean that an organization using Perl, C++ or Java would endorse functional vs OOP/procedural approaches even in those languages

For the purposes of this language, "large" is defined as large enough to have dedicated development engineering/tools group, which dictates what all the developers are allowed to use/do; and at least hundreds of developers on low end.

Was it helpful?

Solution

There is one very simple argument, which might at least amuse the management.

It is well known that the modern computers are not becoming "faster" like they used to be, because frequency scaling, for now, hit the limit. They increase their potential productivity by adding cores.

This implies that to benefit most from this architecture, the programs have to be parallellized. But parallel programming is way harder than sequential programming, due to a lot of new challenges it brings (consult Wiki article for comprehensive overview).

Functional programming helps to get rid of some of these challenges, e.g. race conditions don't apply if you only use immutable variables and methods without side effects. The learning curve for functional programming is often steep, but the learning curve for parallel programming might be even steeper, and not at all intuitive.

So if the challenge is to write more efficient programs in more efficient way, one can compare costs of training people to write parallel programs with costs of training people to learn functional programming, and the risks both approach might bring.

Regarding mixed languages (which support both functional and imperative programming style): from one point, they might be handy for the transition (people might start using them in the "familiar" way and gradually learn new approaches). From another point, this might be a blessing in disguise, because the potential advantages the functional programming brings might be cancelled with someone's clumsy code. One can mitigate this by establishing clear coding guidelines (see e.g. "Effective Scala" by Twitter), though following the guidelines requires a certain level of team maturity. From this point of view, pure functional languages might be "easier" for software development because of the stricter rules they impose by design.

OTHER TIPS

You are approaching this from the wrong side. In most companies, management is not responsible for "choosing the programming paradigm", they are (or at least should be) responsible for making the team work efficient. If your whole team is convinced functional programming will improve the speed or quality of your work, it should not be too hard to convince management, too. Moreover, if your team just starts to use functional constructs in your established programming languages, and everybody is happy with that, you should not even have to ask for a permission (heck, a non-programmer might not even understand the difference between non-functional and functional constructs, so why do you want to discuss that issue with him?).

But beware, if the rest of your team has a different opinion about FP, and they start complaining about functional code of yours which other team members do not understand, you might run into trouble with management - for a good reason, since in such a case, the team looses efficiency.

So the gist is: convince other team members, or your team leaders, but, not high-level management!

EDIT: due to your comment - actually, this is an answer to your question ;-). The one factual argument I am talking about is "the whole team thinks FP is helpful for doing the job. IMHO that's the argument with the highest chance of beeing accepted by high level management, and it is very practically applyable. Trying to use technical arguments to non-technical people directly seldom works, not because they are "too dumb to understand the technical reasoning", but because they are smart enough to know that technical decisions should be made by technical experts, and they are also smart enough not to rely on the opinion of only one expert.

To understand why Functional Programming hasn't taken over the world, you have to understand the corporate thinking behind programming language decisions. To pick on Java for a moment:

  1. There are armies of programmers available that can write reams of ordinary Java code. This is not true of Lisp or Haskell (or even Scala) programmers.
  2. Everyone else is using Java, so it must be good. Corrolary: managers don't have to justify their choice of Java versus some obscure language nobody in the command structure has ever heard of.

If your organization is already entrenched in the Kingdom of Nouns, making a wholesale change to Functional Programming is just not going to happen. The language choice (and all the other choices that surround it) is already deeply embedded in the corporate culture.

Assuming your goal is to grow as a software developer, your best bet is to

  1. Incorporate functional concepts into your existing programs where they are useful and appropriate,
  2. Use new functional language features as they are added to the language, and
  3. Learn object-oriented design patterns, some of which exist to overcome the language deficiencies in OO languages that are not present in Functional languages.

Paul Graham's arguments really only apply to startups, and there have been a number of cautionary tales of companies that started out using purely Functional languages, but then they got bought out by another company whose first order of business was to immediately convert the functional code base to an OO language so that their existing software developers could understand it.

In my (somewhat cynical) experience, having worked for a shop where we did use functional programming, and interviewed at several others:

  1. There was always a CTO and other high-level technical people who had experience with functional programming and managed to convince the non-technical executives of it. (And incidentally, these folks are better qualified to answer your question than I am.)
  2. Once these folks leave the company, and get replaced by folks who don't have this inclination, things will go south. The new guys will blame everything that goes wrong (including, and particularly their own failings) on the weird programming language and paradigm used to build what came before. They will marginalize the remaining folks with functional programming skills, pushing them out of the company. The system built on the functional language will deteriorate unmaintained. This sort of thing, in my mind, the biggest risk that a business takes on if they adopt a functional language, and must not be underestimated.
  3. The organization has to have a "build instead of buy" culture for this to work. Because adopting a functional language will mean fewer "buy" options.
  4. There was almost always some compromise to the technical and non-technical detractors of the idea. The most common of these compromises is that any non-JVM language was just out of consideration; Clojure and Scala were proposed, Haskell and O'Caml were just out right off the bat.

Things to consider for upper management when/if upper management is involved in selecting programming languages (which is odd, they should leave it to trusted, knowledgeable people (both technology and business savvy):

  • Productivity
    • Both current and future employees
    • All roles (architects, developers, testers, OPs, ...)
  • Supported platforms
    • Operating systems, (hardware?)
  • Publisher of the language/platform
    • Licences
  • Maturity of the language/platform
    • Support of/by the publisher and/or community
    • Libraries
  • Migrating current code base
    • Or integration with

Note that these are not specific to functional programming languages. These are also no arguments unless you provide data with these. We cannot give you the data as they completely depend on your business' environment. The only thing we could do is collect data from the web to show how much knowledge and interest there is for a specific language. Be careful when translating many questions on StackOverflow or many tags on Linkedin into a language being popular.

I don't think arguments or facts will help. And certainly not without stating the problems you want to solve.

Against common believe and typical self evaluation many decisions are made based on gut feeling. And often these decisions are very good decisions, because they incorporate on a subconscious level a lot of experience of the individual making the decision.

If you want to challenge such a decision like "We'll stick to C like language until the end of all computers" you have to do more than just provide some arguments.

The first step is probably to uncover the persons and reasons behind the decision that senior management should have a saying in such technical decisions. Of course I can only guess here, but very likely they have quite a track record of decisions made by technical personal gone bad. Let's face it: Most developers aren't very good at making (even technical) decisions on a company level.

Once you found these people talk to them in order to gain there trust. Possibly the best approach is: listen to them. What are they concerned about, what are the risk and chances they see. What are problems they are challenged with. From here you might move to get technology people involved into this kind of decision. Management often doesn't really want to make these decisions, but doesn't trust others with it. So if you team starts to get involved into architectural decision and demonstrate that the decisions you propose are sound management might be willing to trust you/your team.

Important in order to come up with sound architectural decisions is:

  • Gather input from stake holders (Management, Users, Administrators, Sales, Clients ...)
  • Base decisions on that input
  • Communicate clearly: What the (proposed) decisions are; What risk they aim to mitigate; What conflicting interests are and with some delay: how well they worked.

If you work for a large company with say 10K+ employees, be prepared to learn some of the following lessons.

  • speed of coding isn't really relevant for the bottom line.
  • things like maintainability on the scale of decades is.
  • the problems you think you can solve using functional languages aren't really relevant for the bottom line
  • problems like training 1000 developers, the natural resistance to change and maintaining a code base written by developers with less than 5years experience in the technology used are.

Once you reached a level of trust that your arguments are heard and considered you will also have established a way of gathering and considering requirements that you, your team and management trusts.

If this process produces the recommendation to use a functional approach in certain areas you are done.

If this process produces the recommendation to ignore functional approaches going beyond what the current main programming language offers you are done as well.

The bad news is: Depending on the size and style of the company this might easily take a couple of years or decades.

The good news is: You will learn a lot on the way.

Since the first step is to start to talk and especially listen to senior management I'd recommend starting with reading Just Listen.

One good approach would be to show that it's shown good results in the industry and adopted.

You can get some data from:

Ideally, try to talk to the managers at some listed companies, especially if in your industry, and get numbers and testimonials from them.

Google has many other similar links for Haskell, OCaml, etc.

You're coming at this from the wrong direction.

You're trying to convince management of a switch to a functional paradigm for your own amusement and you're trying to rake in arguments to support this that have got nothing to do with the real reason why you want it. Otherwise you wouldn't need to ask the question, because you'd be able to list your arguments from the top of your head.

Rather, what you should be thinking about is what the current business need is and how it is best served. If it so happens that it is best served using a functional paradigm then - yay! - you get to play. But if you do a fair analysis, taking into account operational business needs, necessary training of co-workers, backgrounds of future programmers, maintenance, and so on and so forth, often it won't be.

Senior management with no technical skills shouldn't care about technical aspects such as the usage of functional paradigms. This is not their domain of expertise, and smells micromanagement. Why aren't they delegating those decisions to persons who actually have required skills?

This being said, here are some hints to convince people with technical background (first case) and those without one (second case).

First case

If you're talking to people who know programming, comparing code written without functional programming paradigms and the same code written in functional style may be convincing enough:

Sample C# code which uses imperative style:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

Same code rewritten with functional programming in mind:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

Then ask them:

  1. How many mistakes can a programmer make in the first sample? What about the second one?

  2. How difficult is it to spot mistakes?

  3. How difficult is it to modify code?

All three factors influence productivity, and so the cost of the product.

Second case

If you're dealing with people who don't know programming, there is no much technical stuff you can tell them. One of the ways to be convincing is to show the actual impact of functional paradigms on your work and the work of your coworkers.

For example, compare two projects made by the same team, one using FP, other not using it. Showing that the number of bugs is much lower or that this was the first project the company actually delivered on time should be convincing enough.

Licensed under: CC-BY-SA with attribution
scroll top