Tag Archives: functional

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?

Is ‎Object Oriented the best?

I’ve been hearing sincere complaints lately about object oriented programming, about the Craftsmanship Movement, about Agile development practices. I hear from folks who are excited about functional (denotative) programming, who write concise little functions with one character names. (Some have objections to TDD, or think pairing is costly, but those are on the edge of what I’m talking about). And I’ve been wanting to really listen.

And of course, I hear a lot from folks who love TDD, love Object Oriented structure, love pair programming and long method names. And those are the folks I hang with, for the most part. So I’m wanting to listen to all of it, and see what I hear.

Though I sometimes hear that Object Oriented is “just better” or that TDD is “always appropriate” — what I call Argument From Fist-on-Table — that idea doesn’t help me much. In listening, I’m looking for better at what? and appropriate to what end?

So for many months I’ve been wondering why I’ve been pretty content to love OO programming (though I can see the mathy beauty of FP*) and why I love the things that get called “clean code” (without loving the setting of it as a categorical imperative). Talking to @kaleidic this morning in the wee hours, I realized what it is that I love about them.

I love the whole shebang — “craftsmanship”, TDD, the Four Rules of Simple Design, long names, etc. — because I love collaboration. Not just because it’s juicy and fun, but because it supports the emergence of good systems, and things like flexibility, responsiveness, changability. I love having a shared code base, and object oriented “craftsmanship” is a strategy for getting that.

I also love evolution, and folks following the sparkly stuff, so when I see smart friends like @kaleidic and @conal and @tunixman railing against object oriented programming, for example, I’m excited about what they’ll come up with. But I realize that whatever techniques emerge, they won’t just have to be about faster or even more accurate code to make me love them. They’ll have to fit into the collaborative social structure that makes Agile so beautifully effective.

* Really itching to work on Conway’s Game of Life without state changes, in fact.

A question anyway

So I answered this question for myself, but I am still curious. What is important to you about your preferred style of coding? If you’re an Agile developer, why do you love long names and TDD and objects? If you’re a Functional / Denotative Programmer, what do you love most about your code? Can it be made collaborative in the way I’ve described?

Can there be Agile functional or denotative programming?

Somebody tweeted that they don’t like OO, and it made sense to me, because a few people I’m close to feel the same. Something’s bugged me about the anti-OO idea, though, and I just realized what.

Agile programming to me seems like a big, creative party. Like a barn raising, maybe.

If OO were thrown out in favor of the purest form of Haskell, for example, what would that look like? What kind of collaboration would happen? Pairing? How? What would we test, and when?

What would it be like working on a scrummy, xp-like denotative programming team?

GeePaw limps along with…

Beats hell outta me.

I spoze I could make some knowledgeable-sounding thing up.

True story: I do not know.

True meta-story: Is better to not know than to know wrong, or to make things up.

If I have a team who does functional or denotative programming, I’m certainly willing to try.