Tuesday, May 27, 2008

On the concept of Form (3): the Force Field

Warning: :-) this post is going to be somehow conceptual. I'll soon move to some real-world, software-based example, but I really need to introduce some concepts first.

The notion of force field might be unfamiliar to some, so I'll borrow a great example from Alexander himself. Consider your first "requirement" (for a system yet to be built) as a permanent magnet of some size and shape. If you place a flat glass over that magnet, and drop some iron filings on it, the iron will naturally dispose along the magnetic field lines. That gives us an image of [a section of] the force field. Now add another magnet: the shape of the field will change, as the magnets are interacting, thereby shaping a more complex force field.
We can change the [shape of the] field in many ways: moving magnets around, changing their shape, their magnetization, or even adding some shields around magnets.

The great thing about the magnetic field is that we can somehow observe its shape. Indeed, if our goal was to create a form that can be put into effortless contact with the field, we'll just have to replicate the same form that the magnetic field is giving to the iron filings. As Alexander says (NoTSoF, page 21), "once we have a diagram of forces [...] this will in essence also describe the form as a complementary diagram of forces".
In the real world, and even more so in the software world, we are never so lucky: the force field is invisible and tends also to be highly unstable.

Usually, the force field of a software project starts with Requirements. Requirements are often categorized in some way, like "functional" and "nonfunctional", or "user requirements" and "system requirements. However, requirements of any kind are just like magnets: they contribute to shape the overall field.

Requirements are just one kind of force, that is, they are not alone in shaping the field. Many technological choices we make, sometimes very (or too) early, are also shaping the force field.
Consider a simple business application. Once you decide that you'll build a web application, you have added quite a few powerful magnets. If you're familiar with JSP and EJB, you are naturally tempted to choose those technologies early on. That's like adding quite a few powerful magnets again. Or maybe it's like adding a magnetic shield: it really depends on context.

Sometimes, technology makes the field simpler: the right infrastructure should simplify the field, that is, it should act more like a shield than like a magnet. In this sense, infrastructure should be chosen when the dominant forces are known, unlike what happens in many projects, where infrastructure (usually a superstructure in disguise) is chosen too early, thereby making the overall field even more complex.

We also shape the field, so to speak, by choosing what to ignore and what to postpone in any given release. Anything we ignore, like anything we postpone, won't be allowed to shape the field right now.
This is fine, as long as the corresponding magnets will be placed somehow distant from the others (good modularity), possibly with some kind of magnetic shielding in between (stable interfaces). It's also fine if we can ignore it forever. Any attempt to temporarily ignore a strictly interacting force will wreak havoc later on, as our form will no longer match the resulting force field. Refactoring can accommodate minor misfits with the ideal form, but won't help much when the force field changes radically (see also my notes on refactoring here).

Here lies one of the architect's fundamental abilities: the intuitive understanding that something can be beneficially postponed, while something else must be dealt with immediately, because its influence on the force field is so strong that doing otherwise will shift us toward the wrong kind of form.

It is important to understand the role of choice in exploiting instability. Too often, software developers tend to see requirements as "fixed". They don't like to negotiate: it's much easier to fight the compiler than the marketing guys.
A good architect, however, can't miss the opportunity to simplify the field by moving some magnets around. That requires the ability to see the overall picture and the fine details at the same time. Here is Alexander again (page 18): "this ability to deal with several layers of form-context boundaries in concert is an important part of what we often refer to as the designer's sense of organization. The internal coherence of an ensemble depends on a whole net of such adaptations".
That ain't an easy feat. It requires an understanding of the business, the users, and the technology. And even more important, it requires a willingness to act on that knowledge. The power of choice extends to the infrastructure: sometimes, by willingly postponing a technological choice until the force fields takes shape, we can make a better, more "natural" choice.

This can be hard for some developers: they want certainty, and they want it now. In my experience, that goes in pair with the willingness to adopt a sub-optimal, but repetitive and context free solution for a wide class of problems, instead of adopting several optimal, but reasoned and context-dependent solution for smaller classes of problems.

Unfortunately, choosing the "wrong" technology is very much like choosing the wrong shape or orientation for a building. To quote Alexander once again (page 29): "Instead of orienting the house carefully for sun and wind, the builder conceives its organization without concern for orientation, and light, heat, and ventilation are taken care of by fans, lamps, and other kinds of peripheral devices. Bedrooms are not separated from living rooms in plan, but are placed next to one another and the walls between them stuffed with acoustic insulation".
I think we can easily see a parallel with software here: a misfit technology is chosen early on. As a consequence, you find yourself adding more and more technology (fans, lamps, insulation) to satisfy the end-user needs. "Modern" web applications seem to have taken this path: faced with a difficult field, they're layering one technology on top the other, desperately trying to overcome the problems of the previous layer.

Next time, in no particular order: agility, unstable requirements, early coding, TDD, "seeing" the field, internal and external representations, is UML any useful, order within chaos (dominant forces), constructive force field and systematic techniques, and whatever else will come to my mind :-).


Anonymous said...

Very interesting post, Carlo!
But let me poit out that not only developers want certainty now: often the management (and also the customer itself some time) imposes such need of certainty to the team.
What a designer can do to avoid this situation, I cannot say!

Carlo Pescio said...

Antonio: absolutely right! Of course, the kind of certainty they want is different, and the designer has to deal with that too.

Given the strong correlation, I'll talk about that when I'll touch on agile methods in the context of the force field. Thanks for reminding me!

michelangelo said...

Pongo qualche domanda cui non so dare risposta.

Restando nella metafora del campo di forza, che rapporto deve esserci tra la forma del campo e quella della soluzione perche' questa abbia i caratteri della Qualita'?

Supponiamo di avere un campo gravitazionale (ma lo stesso si potrebbe fare con quello magnetico) e il problema di attraversarlo con un veicolo. La soluzione migliore credo consista nel seguire una traiettoria allineata il piu' possibile alle linee di campo (almeno in buona parte) per sfruttarlo ed evitare di deformare il veicolo.

Siccome anche il veicolo altera il campo la traiettoria dovrebbe essere allineata con le linee del campo risultante.

Il contesto di un progetto sw e' l'ambiente umano-sociale-culturale in cui diversi elementi creano qualcosa di simile ad un campo di forze. Alcune di queste forze (esigenze) inducono alla costruzione di artefatti software che devono essere adatti al contesto (in verita' il loro uso alterera' il contesto come nel caso del veicolo).

Ma cosa vuol dire adatti? La metafora continua a valere e ci suggerisce forse che debbano essere allineati con la forma del campo? E questo cosa vuol dire? puo' la metafora darci qualche indicazione?

Carlo Pescio said...

Michelangelo: ottime osservazioni, come sempre. Sicuramente approfondiro' nei prossimi post, pero' giusto per non attendere troppo:

- Le forze in gioco sono tante: requisiti utente, requisiti di sistema, requisiti al contorno, che includono anche vincoli legati al team di sviluppo (distribuzione geografica, competenze, ecc). Il contesto non e' solo umano, in alcuni casi (es. sw embedded) le forze al contorno sono molto "tecniche", in altri casi effettivamente il contenuto tecnico e' relativamente piccolo (youtube, blogger :-)), ma l'impatto sul contesto di riferimento e' molto grande.

- La forma dovrebbe porsi in contatto "frictionless" con queste forze. Per formalizzare il concetto, Alexander partiva da un campo di forze, nel quale tutte le forze in gioco venivano rappresentate, per poi cercare dei sottosistemi di forze (nb: di forze, non di soluzioni) coesive e fortemente accoppiate. Dei cluster nel campo gravitazionale, per riprendere il tuo esempio. L'idea essenziale diventava quindi la separazione in sottosistemi ad accoppiamento minimo, che gia' conosciamo.
Sembra storia vecchia, ma ci sono ancora molte intuizioni da esplorare e da trasferire.

- Va detto che nel campo del software ci sono spesso liberta' enormi che non cogliamo: da qui la forte correlazione con altri temi che mi stanno molto a cuore ma non riesco mai a trovare il tempo di discutere, ovvero la possibilita'/necessita' che gli analisti inventino i requisiti, e l'efficienza creativa come sweet spot all'incrocio di competenza tecnica e di marketing (lontani quindi anni luce dai contrasti/negoziazioni che di norma si verificano tra questi ruoli).