Breaking Out Of The Fear Cycle
- Cautionary Tales
(I'm not sure which one applies the best here)
- Keynote (40m)
We are here, speakers and delegates alike, because we believe (or at least have a hunch) that developing software using functional programming principles will lead to better products, systems and developer experiences. But isn't it surprising how often we find ourselves evangelising the benefits of FP only to find external factors and delivery pressures blocking our way?
This talk is based on personal experience being in this situation while working for one of the few UK tech unicorns* based in the north of England. Like many companies, we've been through various phases of growth, all building on a monolithic OOP codebase:
- The outsourced phase
- The early in-house phase (we're small, agile and rapidly delivering features)
- The awkward scaling, mishapen and unstable phase (the rough edges of early decisions are coming back to haunt us)
- The fear cycle phase (small changes cause bugs and outages so the scope of changes decrease, leading to more technical debt, bugs and slower delivery)
However, we've seen the benefits of using functional programming. Multi-million pound opportunities have been realised through composable, functional JavaScript. Our bug count has decreased and speed to market has improved. Yet, despite this success, we're still fighting to stop people using mutable state, leaky abstractions (classitis) and code so full of side effects you can't write a test without first having to mock the majority of the application. Scaling teams and the software they produce is hard!
Hear how we navigated the choppy waters of internal politics and non-functional constraints to help refactor our products into our vision of programming perfection. Leave with new ideas how you can spread the passion for FP and identify opportunities to use your skills to drive value for your customers and business.
*A unicorn is a private business valued over £1b.
No matter their experience, attendees will likely have come across similar problems to those we've faced. It can be a frustrating and demoralising challenge to change the habits of a small team, let alone a whole organisation. Sharing the highs and lows of software engineering moves us forward as a community, starting conversations which help improve our work.
This talk will challenge the audience to think critically about the craft of software engineering and will equip them with ways to spread their knowledge and champion FP techniques to help improve their own products and systems. Even if your core languages are PHP and JavaScript.
The talk title references and article by Michael Nygard called "The Fear Cycle" - http://www.michaelnygard.com/blog/2015/07/the-fear-cycle/
According to Michael the fear cycle goes like this:
- Small changes have unpredictable, scary, or costly results.
- We begin to fear making changes.
- We try to make every change as small and local as possible.
- The code base accumulates warts, knobs, and special cases.
- Fear intensifies.
Michael's article goes on to describe how unexpected errors and outages lead to management interest and increasingly poor choices to narrow the scope of a change and reduce the chances of problems occuring. I've seen this first hand and like many other developers I looked to the principles of functional programming to see if there was a better way to build software which breaks us out of the cycle. I believe it did, but what about everyone else?
I work on a single page app (SPA) which is used by more than 2 million people each year. The app is loaded roughly 140 million times a month (making more than 880 million AJAX requests) and is comprised of many thousands (millions?) of lines of code contributed to by hundreds of different developers. It also is responsible for several billion pounds worth of turnover so we can't just rip it up and start again but as is so often the case we sometimes wish we could!
Delivering software at scale is hard, but not always for the reasons you might think. Working on a codebase that is several years old and been exposed to the best (and worst) aspects of agile delivery often requires more than just coding skills.
There's a famous quote from Joe Armstrong, the creator of Erlang, which talks about the lack of reusability inherent in object-oriented languages:
"You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."
This quote captures more than just the benefits of one programming paradigm over another, it completely and accurately describes the challenge of working on codebases of any reasonable age, complexity or scale. Your code has context, a history, a messy mix of political decisions, personal passions, passing fads and bad design choices which is carried by every commit a developer makes.