Sunday, December 16, 2007 

On the concept of Form (2)

In the Notes, Alexander defines form in a rather unique and interesting way: "The form is the part of the world over which we have control, and which we decide to shape while leaving the rest of the world as it is. The context is that part of the world which puts demands on this form; anything in the world that makes demands on the form is context. [...] We want to put the context and the form into effortless contact or frictionless coexistence" (pg. 18-19).

Alexander's definition goes well beyond the old-school, classical dichotomy between form and function, and also beyond the old-school dichotomy between functional and non-functional requirements. In fact, function intended as purpose is part of the context: functional requirements are obviously putting demands on form. Non-functional requirements are part of the context as well, and they should be considered first-class citizens too.

It is important to understand the human role in the design process. It is first an act of selection, and then an act of shaping.
We decide to shape a part of the world and leave the rest as it is. These are powerful words. I've long contended that in most case we have a much higher degree of control over requirements (context) than we're inclined to believe.
I've also contended for a very long time (mostly inspired by Tom Peters, I guess) that efficiency demands requirements (that is, context) to be developed jointly by developers and marketing.

Move away from this, and you get an inefficient context: a set of requirements (mostly functional) which may put strenuous demands on the form, without a corresponding premium in the resulting value. If you wanna win the game, you have to set the right rules.
In software development, more than in any other discipline, we can choose the right context before we step up to build our product. Of course, it is much easier to get a "fixed" set of requirements, complain about marketing lack of understanding, and start coding. But that's just not efficient. Also, keeping the context fixed while we shape the form is inefficient, as we wouldn't be profiting from newly discovered opportunities.

Building form, therefore, is an incremental process of discovery, as we don't know the exact context, and even if we do, we don't know if that's the context we wanna play with (or against, if you're the competitive kind ;-).
Indeed, Alexander reminds us that "In a real design project [...] we are searching for some kind of harmony between two intangibles: a form which we have not yet designed, and a context which we cannot properly describe" (pg. 26). It is not hard to see a deep connection with the notion of "software development as knowledge acquisition" popularized by Armour.

It is also important to understand a simple, yet deep consequence of Alexander's definition of form. As we create a product, even a software product, we are shaping its form. Even if we ignore design altogether, or even if we just concentrate on making it work, we are shaping some kind of form.
In most piecemeal development cases, that form will be determined by a small subset of forces: functional requirements, and sometimes the viscosity of previously developed software as well. The resulting structure won't be in frictionless contact with the true context, and the resulting friction will make our product brittle.

There is still a lot to be said about the subtle relationship between the above and agility, about the concept of shaping software, the [constructive] force field, and about the ubiquitous real options as well. Some more software-oriented examples are probably badly due too. And I should really say something about inventing requirements! So many things, so little time :-). Stay tuned!

Labels: , ,

Comments:
Scusa se porto il discorso a livelli un po' terreni, ma cercavo di immaginare l'evoluzione della forma di un sw durante il suo sviluppo.
Non ci riesco... :-)
Che cos'e', concretamente, la forma del sw? C'e' modo di vederla mentre guardo un sw? Un sw fatto bene ha una bella forma? E un sw bello e' fatto bene?
 
Citrullo, per una risposta alle prime due domande, direi che dovrai portare pazienza :-).

La questione estetica non e' banale. Alexander non la tratta in modo esplicito, ma va anche detto che nel caso di artefatti fisici alcuni vincoli estetici possono rientrare tra le forze che definiscono il contesto.

Puo' venire naturale associare ad alcune proprieta' (ad es. la simmetria) una "bellezza" ed una "bonta'" intrinseche. Tuttavia questo va contro l'idea fondamentale di Alexander: la forma "fatta bene" (per riusare le tue parole) e' quella che si pone in frictionless contact con il contesto. Una forma "bella" (qualunque cosa voglia dire) che tuttavia non e' in frictionless contact con il suo contesto non e' fatta bene.

Mi rendo conto che possono sembrare temi un po' troppo concettuali, ma invito ugualmente chi ha un interesse a comprendere piu' a fondo cosa facciamo mentre progettiamo il software a prenderli come spunti di riflessione.

Citrullo, un'ultima cosa: prendendo spunto da un recente commento lasciato ad un vecchio post, e conoscendo la vostra dimestichezza aziendale con la lingua inglese, che ne dici di fare contenti i lettori non Italiani? (e di dare il buon esempio:-)
 
Ok: "you have reason, let's give the good example"! I heard these words from a colleague of mine... after few weeks, our company started english training. The colleague meant "you are right, we have to be a good example". Now he works abroad and speaks english all the day. :-)
 
Citrullo. I hope this sound as a career enhancement...
 
More than a career enhancement, it was a wonderful career begin! ;-)
 
Post a Comment

<< Home