Beyond the Business Case
This post is an expansion of a presentation that I gave at the first Miami Functional Programming meetup. The basic motivation is that there are an enormous number of presentations and talks floating around about making the business case for functional programming, but I find that those are often not very effective in real business settings. The issue is that they often talk nuts and bolts, dollars and cents, and in real life that's not entirely how decisions are made. Of course, that part is necessary--a bad business case should be a non-starter for making a choice in an enterprise context--but it's not generally sufficient for getting a real change to happen.
This is because a decision to adopt functional programming (or any new technology) happens in a business's cultural context. It's a decision that usually requires several people to accept and to actively push for the change to occur. You have to overcome institutional inertia and the inherent anti-risk bias of businesses. This makes advocating for a new technology a fundamentally political problem: to successfully advocate for a change requires approaching the problem as one of social engineering, not one of dollars and cents. So I've written a guide for how to think more politically in advocating for functional programming.
Step 1: Know Your Local Management
The first step is know who it is you have to convince to make your dreams of pure functions and terse lambdas come true in production. You have to know who they are, and what their specific concerns are.
Before you even start, you must realize that, contrary to popular developer belief, management are not idiots (usually). They're just incentivized differently. In particular, they tend to be risk averse with technology: if a current system allows the development team to deliver a product that management can successfully sell, that's good enough for them. If it ain't broke, don't fix it is their motto. This means that despite what you and I know about how a better software framework will improve quality or delivery schedules, they're not going to trust that too much, or they will focus on the potential downsides (which are real).
Generally speaking, in order to make a serious pitch to management, a developer needs to be prepared with concrete examples. Coming in with abstract notions of software quality ("it'll give us access to cleaner abstractions," "we'll be able to have true microservice architecture with high testability," etc) won't mean a lot to most managers. But if, on the other hand, you can tell them that a particular feature in the backlog that's been continuously punted down the road will suddenly be buildable for free, all of a sudden you have yourself a rapt audience.
You also need to learn management's sore spots. This will give you specific and direct leverage. The idea here is to know what headaches cause an outsize problem for your specific managers. Maybe you have one client who complains about one feature a lot. That feature isn't normally a development priority, because it doesn't represent a major business draw. But it does represent an over-represented sore spot. Now that's a bruise you can poke to make some action happen. You can learn this kind of thing by just being social outside of the dev team in the shop. Talk to your managers, read any company-wide communications that might give a hint as to what the customer service people are dealing with, etc. You'll need to step outside the bullpen for this one, especially if you work in a bigger company.
Step 2: Recruit Allies
Go make DevOps your friends. That's the single most important ally you have in the building. This also shouldn't be too hard, because DevOps and development are natural allies, and you both grok technicalese. Before ever making a pitch to management, make sure that you have DevOps on your team. If they have real technical concerns, they should be able to express them to you, and you need to address them. Once DevOps is won, you get to have a lot of answers really quickly to management concerns. They're worried about additional complexity? Nope, you and DevOps already got it figured out. They don't want to do a major rewrite? That's okay, you and DevOps already figured out how to do interservice communication so you can spin out individual component features. Not only does this actually address concerns (which is important), but it makes it look like you've done your homework (because you have). There is nothing more likely to tear down someone's inertial reservations quite like having every objection shot out of the air immediately, and a DevOps alliance is the highest bang for the buck you can quit that way.
Obviously you also need the seniorest, most wizardly hacker in the shop on your side. The nerd who has been there since the first year, the person that management pulls in to help articulate development priorities, and whose word they just plain take when asking how feasible a project is. That person needs to share your enthusiasm for making a technical migration to the Beam or to Scala or whatever you're planning. I feel like this barely needs explanation.
If there are technical and semi-technical support staff you can get on board, they're good too. People like QA teams, DBA's, testers, all those folks who bridge the gap between development and operations. If you can get all those people on board and enthusiastic about a new paradigm, that tells management that this will have real operational advantages.
If there are key allies you need to recruit who aren't already hyped about a new technology, find ways to workshop them in. We'll get to more of this later, but it's key to spend time talking about the advantages of pure functions over lunch, or using company hackdays to team up with people who have never used pattern matching to solve problems and show them the light.
Step 3: Leverage Your Wiggle-Room
You need to explicitly identify what your cultural freedoms are and the extent of your engineering leeway. If you have the hackdays or lunch'n'learns, these are the cultural freedoms that you can use to get people on board and build conversion momentum. You can use any regular team outings, like Friday lunches, to get everyone together entertaining the ideas and thinking about things.
Which leads us directly to a broader explication of...
Step 4: Ask Forgiveness, Not Permission
There's a lot of options for creativity here. Most shops of any size have purely internal tooling that isn't customer-facing. Maybe it's a script that generates invoices, or a management interface for controlling user rights. If you get asked to build one of those, do it in FP. Spin up your Phoenix boilerplate and ship out a supervision tree. You can then tie that back into steps 2 and 3 by workshopping your colleagues on why you did that and how bleepin' dope it is.
Modern transpilation (or virtual machine targeting) provides a lot of options for building features in new ways. There's about six hundred JS varieties. If you're a Java shop, start writing Scala and don't look back, so far as anyone needs to know you're just shipping compiled JAR's. These are all options.
Whatever you're doing, always be sensitive to the limits of this paradigm, and always make sure you never shirk truly deliverable work for it. Don't write a new reporting engine in Elixir without having it in the existing Rails infrastructure first (trust me: that particular one is from experience.)
Step 5: Making the Business Case
This is where all those other blog posts and presentations come in to play. Now's your time to shine, to walk into management and give 'em what-for.
Remember that sore spot from earlier? Hit them right there. Show them a problem feature you've rebuilt with 100% test coverage and free integration into the existing application. Show them a tool that does highly-granular user behavior analysis, business types eat that right up. Whatever the problem was before, show them how for the low, low price of strong typing and no side effects they can get it.
It's important to remember that, for the most part, you don't need to talk about the stuff that you and I talk about when making this case. Don't bother pointing out that a monad is just a monoid in the category of endofunctors, or that shared mutable state is the root of all evils. They usually don't care, and that kind of messaging should have already done its work in recruiting your allies. Now we're taking those allies and lining them up against the decision-makers, and that's a tactically different category of interactions.
Make sure you have a transition plan, vetted by your senior wizard and DevOps, before you walk into the room. You may not need to go into the details, but have it in hand and ready to go if necessary. Understand what the pipeline will be for feature transitions, whether you intend to just do green field work in the new paradigm, how you'll triage feature ports, that kind of thing. Will you need a tiger team to make the transition? Will everyone need to add the new framework to their literacy? How will you vet new code when not everyone is an experienced Haskell developer? You need the answers to these questions before you start your pitch.
For the first time in your career, sedition in the ranks may be your friend now. Those are the kinds of things that keep decent managers awake at night. If your shop has been showing high turnover or disnegaged developers, trot that right out for the boss: "this is really exciting stuff, and honestly I think it'd be great for team morale." That kind of line wins the day. Of course, never foment sedition that's not already there: it's better to be enjoying your job than it is to be writing pure functions, even if you need mutable objects to do it.
Step 6: Be Ready for Objections
There are some really common objections that you need to be prepared for. Anyone who has ever tried to advocate for a stack change has heard fears of increased stack complexity and additional brittleness. This is why we needed DevOps. You don't need to answer this with metrics about stack complexity or literature on component vulnerability. You need to answer this with exactly one line: "I already talked to DevOps, we have it worked out." If your manager is technical, you can go into details after that, but the cultural and political pressure of knowing that this advocate (you) has already anticipated that objection and solved it is enormous, so that's what you rely on first.
You're also likely to hear concerns about hiring and staffing. This is where having your team on board helps, and knowing your transition plan is key. If you can confidently say that every dev in the shop already knows the technology and is willing and ready to work there, and that you have a plan to teach juniors in this new tech, you can go a long way towards alleviating this fear. However, this is likely the most real business concern you will encounter in this process: hiring Elixir developers is, actually, harder than hiring Ruby developers. So it's likely that your best course of action here is to pivot away from this problem and don't give it too much time. The more you defend it, especially if you're wrong, the more you'll entrench this as an issue in your manager's mind.
Epilogue: Prepare for a Siege
Even with all the prep work of alliance building and scoping out the opposition's terrain and fortifications, you're not likely to win this argument overnight. So be ready to make a long issue out of it. Don't let it die when the boss says "we'll begin exploring it, but right now X takes priority."
Keep workshopping to your colleagues. Keep building whatever you can under your new paradigm. Keep using your hackdays for functional programming accomplishments, and keep advocating for more and more freedoms: securing more hackdays, more group reading, and more developer freedom will only aid you in this mission, and it has the side effect of probably making your other work more entertaining, too.
A solid use of power in a siege context is to infiltrate the hiring process, and internally count FP familiarity as a hiring plus. The more you can bring on staff that already agrees with you, the happier you'll be, and the more power you'll accumulate to effect the change you want to see.
Ultimately, that's what we're discussing here. We're discussing the accumulation, arrangement, and leverage of power to positive ends. So conceive of what you're doing that way. And while you're at it, might as well unionize.