Agile Development is like Object-Oriented programming in many ways –
- They both sound good on paper.
- They’re widely adopted.
- In hindsight, they were both bad ideas to begin with.
What we in the functional programming community are finding out is that its our current software development methodologies that are limiting the benefits we receive from functional programming.
I use to work for a company called Jet.com. They use F# everywhere. But all of their systems are roughly the same magnitude of a mess that they would have achieved with just using C# (maybe it’s half as bad as it would have been with C#).
Their development approach took very little advantage of the modularity constructs provided by F#. I even gave a lengthy and detailed talk at the Empire State Building at the NYC F# meet-up to help them understand how to actually make software modular with F#. A few of the engineers picked up on it, and maybe a couple ended up using it. I used the technique intensely myself to build a new system upon which a significant portion of Jet’s technology platform could be implemented and even modeled after. But only to have my design eroded by a couple of fellow engineers who were in a hurry to satiate the business team.
I spent intense weeks building the world’s first truly debuggable microservice architecture using innovative techniques like Vsync, the debuggable Async monad and cloud-deployable systems that could be configured to run in their entirety and fully sequentially on the developers’ machines directly. Your entire distributed program could be easily configured to run in a manner that was debuggable as if it were a monolithic, single-threaded program.
It really was a significant development.
But did it have any long-term impact, despite my Herculean efforts and fundamental innovations?
Collective code ownership.
And a total lack of architectural sovereignty. I didn’t even have the power to block this stuff with a code review — just slipped right through.
The most important design constraints I set up to make this system incredibly developer-friendly, understandable, and most importantly, reliable were quickly bulldozed by short-sighted code slingers. And if functional programming is about anything, it’s about adhering to principled constraints to improve our code. Outside of forcing everyone to use Haskell, you won’t be able to uphold your system’s design constraints in such an environment.
Repeat this story over the life of the company, and you have what Jet’s internal technology looked like to me when I was there.
It just doesn’t have to be this way. But it will not change until the sophistication of our development processes is upgraded to match the sophistication of our programming techniques. I absolutely applaud Jet’s adoption of F# — it’s what brought me to the company amidst a cold and lonely New Jersey winter!
The problem is that Agile development effectively negates most of the value developers can get out of functional programming. Almost to the point where, as I said above, you might as well continue to use C#. At least you could find your code monkeys that much more readily (and avoid ‘non-team players’ like me who actually want to protect the integrity of your systems).
Or, you can evaluate new development methodologies like Sovereign Software Development. I strongly believe that going from Agile Development to Sovereign Development will be like going from Object-Oriented to Functional programming. Engineers will be happier, more productive, and management will spend less time screwing with us.
Hope you love this article. For more details follow us on I’m Programmer.