OOP, FP and UX

A seemingly growing band of programmers with an object-oriented programming background are beginning to take an interest in functional programming. I’m one of them.

Functional programming helps recovering object-oriented programmers to re-develop their awareness of users’  interactions that apply functions for a purpose in a given context. Well, at least it helps this one doing so. (And this is not a rant against object-oriented programming, design or analysis.)

With my new little hammer, I see nails everywhere, even in some unlikely places: In some discussions on user experience I have experienced an extremely strong focus on designing individual pages (and page fragments). I was surprised I had to make the case for exploring content architecture and content strategy concerns against some user-experience designers in some situations. What puzzles me these days is that I run into situations in which I have to make the case for exploring interactions and flows on and across pages.

Are the situation of some object-oriented programmers and the page-focused user-experience designers similar? Would such user-experience designers benefit from re-developing awareness of users’ interactions that apply functions for a purpose in a given context? Would starting with user journeys, interactions and flows be beneficial?

If this sounds like rant against user-experience designers, may I remind you of the second paragraph? I went as far astray as anyone…

Functional flow and structural composition

Architectural descriptions of software-intensive systems often begin with a description of the system’s structural composition. This technical inside-out perspective has made me feel uneasy for quite a while.

In contrast, I like to take an outside-in perspective and begin describing a system by discussing its purpose and the context in which the system will be used in pursuit of this purpose. More concretely, I like to talk about a system’s functions and how work flows through the system when exercising these functions. Working mostly on e-commerce sites, this often means describing user journeys and interaction flows.

And eventually I describe which structural elements collaborate in order to realize these functions. At times, the required mapping of functions and interactions to interacting components and collaborating objects feels tedious and strained.

As I’m learning more about functional programming, I wonder whether describing the architecture of a system built using a functional programming approach will feel more natural? Will the rift between the functional and the structural perspectives diminish as I gain experience with composing functional solutions to non-trivial problems? Or should that read functionally decomposing non-trivial problems?

---

Also see Function & information: a useful duality? on my previous blog, On Service Design.