Functional agile: how does it work?

So I was thinking in the shower about how agile technical practices and functional programming both aim for something like “good” code, but then it occurs to me that — no surprise — “good” doesn’t tell me much.

I want to listen to what each “side” is excited about — not for “niceness” or for getting along or for unicorns and rainbows, but because I am all juiced about both, and I want to share that juice so I have more people to play with.

My first thoughts are that functional talks about correctness, and agile talks about utility. Functional programmers want clarity of vision, I think, with a precise understanding of the solutions they create, so they’re as simple as they can be, reusable and composable. And maybe agile developers are thinking about extensibility, maintainability, helping coders with stuff like staying focused, learning new stuff, avoiding getting buried in complexity.

I am guessing each would smile heartily at the things that motivate the other.

The thing that got me excited this morning was noticing that agile — even the technical practices — is about people. Pair programming, test-driven development, specification by example, and continuous integration are strategies for getting working, extensible, maintainable code, given that we are creative beings, going through life reaching for treasures without being able to predict the results of what we do. I call us mistake-makers; we poke at things and sometimes like what happens. We have brilliant days, and low energy or sad or un-brilliant days. We often don’t know what a solution will look like until it begins to take shape, and our solutions often involve learning, collaboration, discovery.

Here’e what I want to know: how do collaboration, discovery, emergence of solutions, and other agile values fit with functional programming? And as agile devs become fascinated with functional programming, what changes? Does this mean they leave their agile peeps behind? Or does the new functional stuff they’re discovering become part of their agile world?

3 thoughts on “Functional agile: how does it work?

  1. Jason Catena

    I program functionally because I can’t stand to look at complex code. At the very least, I replace every for loop I can with a map, reduce, or filter of a function over a structure of data. This allows me to stub out the function with a debugging one, or call the function with controlled input data. In turn, this allows me to develop incrementally, and write the minimum bit of code that could possibly work. This also fixes the interface between the code and the data it’s working on, which leads to more modular, easier-to-understand code, composed of parts which are hopefully so simple they’re obviously right. I can chart my progress on these little bits through something like kanban, where I have many parts in backlog, a few (never more than 5 or so) ready to write, just one or two in-progress, several that are complete and pending acceptance, and then finally an archive of completed work. This serves me well as a consultant, where work is relatively small and piecemeal, and completion of it changes priorities and what is possible in the given time. The upshot of all this is that having a library of functional bits to work with well complements for me working in an agile approach. (I prefer kanban over scrum, because kanban limits work in progress, easily works with constantly changing priorities, and measures throughput of small units to predict performance rather than relying on estimates.)

  2. rdm

    From my point of view… ok, yes, “agile” is a comment about working with people and “functional” is a comment about working with machines… and…

    … and … what I like about “functional” is that I can re-use and retest in a new context without having to worry about carry overs. I can extract a bit of code and see how it works. I can replace it with something which documents what data it is getting. I can experiment and try things which help me build up my picture of what I am working with.

    … meanwhile… agile also has its own experimental aspects though we come at them from different angles. And, because it’s about people, … well.. people are way beyond complex except where we understand them. But agile also has many elements of observing and awareness and trying things. And I think we somehow need to engage ourselves, otherwise we can fool ourselves into thinking we understand something that we do not.

    1. William Payne

      @rdm – From my understanding, both “functional” and “agile” are about people –

      “Agile” is concerned with how we approach the management of resources in environments that contain risk factors that cannot be a-priori controlled. Specifically, it is about increasing the tolerance of systems and processes to unanticipated change.

      “Functional” is concerned with how we reason about problems, suggesting a perspective that values a decomposition of the problem into stateless declarative truths over a decomposition of the problem into stateful (albeit small and easy to understand) components (each a small simulacrum of some corner of the problem domain).

      (Here I am assuming that there is a close (identity?) relationship between a complete analysis of the problem and the solution to that problem).

      It should be possible to behave in an agile manner with both functional and (well designed) OO models, but in my mind, the statelessness of pure functions makes it very much easier to reason about them, and the implications of using them, in unanticipated and rapidly changing situations.

      In other words, functional programming is a human –> human communications mechanism, where the extra rigor that the statelessness requirement imposes reduces the number of possibilities that the reader must consider when attempting to modify a model to meet a changed requirement.

      Summarizing: “Agile” and “functional” programming are different beasts, but the “functional” approach is very well suited to agile development by virtue of it’s enforced “discipline” of statelessness and corresponding reduction in degrees-of-freedom, resulting in reduced mental burden on the maintainer.

      Extrapolating: It appears that the more “disciplined” the modeling and programming paradigm, the easier it is to modify and manipulate those models, and to operate in an agile manner, so whilst disciplined programming techniques are not necessarily required for an agile approach to development, the ease with which the agile approach may be taken up benefits greatly from the adoption of disciplined programming techniques.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>