Sunday, February 22, 2009

Notes on Software Design, Chapter 4: Gravity and Architecture

In my previous posts, I described gravity and inertia. At first, gravity may seem to have a negative connotation, like a force we constantly have to fight. In a sense, that's true; in a sense, it's also true for its physical counterpart: every day, we spend a lot of energy fighting earth gravity. However, without gravity, like as we know it would never exist. There is always a bright side :-).

In the software realm, gravity can be exploited by setting up a favorable force field. Remember that gravity is a rather dumb :-) force, merely attracting things. Therefore, if we come up with the right gravitational centers early on, they will keep attracting the right things. This is the role of architecture: to provide an initial, balanced set of centers.

Consider the little thorny problem I described back in October. Introducing Stage 1, I said: "the critical choice [...] was to choose where to put the display logic: in the existing process, in a new process connected via IPC, in a new process connected to a [RT] database".
We can now review that decision within the framework of gravitational centers.

Adding the display logic into the existing process is the path of least resistance: we have only one process, and gravity is pulling new code into that process. Where is the downside? A bloated process, sure, but also the practical impossibility of sharing the display logic with other processes.
Reuse requires separation. This, however, is just the tip of the iceberg: reuse is just an instance of a much more general force, which I'll cover in the forthcoming posts.

Moving the display logic inside a separate component is a necessary step toward [independent] reusability, and also toward the rarely understood concept of a scaled-down architecture.
A frequently quoted paper from David Parnas (one of the most gifted software designers of all times) is properly titled "Designing Software for Ease of Extension and Contraction" (IEEE Transactions on Software Engineering, Vol. 5 No. 2, March 1979). Somehow, people often forget the contraction part.
Indeed, I've often seen systems where the only chance to provide a scaled-down version to customers is to hide the portion of user interface that is exposing the "optional" functionality, often with questionable aesthetics, and always with more trouble than one could possibly want.

Note how, once we have a separate module for display, new display models are naturally attracted into that module, leaving the acquisition system alone. This is gravity working for us, not against us, because we have provided the right center. That's also the bright side of the thorny problem, exactly because (at that point, that is, stage 2) we [still] have the right centers.

Is the choice of using an RTDB to further decouple the data acquisition system and the display system any better than having just two layers?
I encourage you to think about it: it is not necessarily trivial to undestand what is going on at the forcefield level. Sure, the RTDB becomes a new gravitational center, but is a 3-pole system any better in this case? Why? I'll get back to this in my next post.

Architecture and Gravity
Within the right architecture, features are naturally attracted to the "best" gravitational center.
The "right" architecture, therefore, must provide the right gravitational centers, so that features are naturally attracted to the right place, where (if necessary) they will be kept apart from other features at a finer granularity level, through careful design and/or careful refactoring.
Therefore, the right architeture is not just helping us cope with gravity: it's helping us exploit gravity to our own advantage.

The wrong architecture, however, will often conjure with gravity to preserve itself.
As part of my consulting activity, I’ve seen several systems where the initial partitioning of responsibility wasn’t right. The development team didn’t have enough experience (with software design and/or with the problem domain) to find out the core concepts, the core issues, the core centers.
The system was partitioned along the wrong lines, and as mass increased, gravity kicked in. The system grew with the wrong form, which was not in frictionless contact with the context.
At some point, people considered refactoring, but it was too costly, because mass brings Inertia, and inertia affects any attempt to change direction. Inertia keeps a bad system in a bad state. In a properly partitioned system, instead, we have many options for change: small subsystems won’t put up much of a fight. That’s the dream behind the SOA concept.
I already said this, but is worth repeating: gravity is working at all granularity levels, from distributed computing down to the smallest function. That's why we have to keep both design and code constantly clean. Architecture alone is not enough. Good programmers are always essential for quality development.

What about patterns? Patterns can lower the amount of energy we have to spend to create the right architecture. Of course, they can do so because someone else spent some energy re-discovering good ideas, cleaning them up, going through shepherding and publishing, and because we spent some time learning about them. That said, patterns often provide an initial set of centers, balancing out some forces (not restricted to gravity).
Of course, we can't just throw patterns against a problem: the form must be in effortless contact with the real problem we're facing. I've seen too many good-intentioned (and not so experienced :-) software designers start with patterns. But we have to understand forces first, and adopt the right patterns later.

Enough with mass and gravity. Next time, we're gonna talk about another primordial force, pushing things apart.

See you soon, I hope!

12 comments:

Romano Scuri said...

Carlo, sta sfumando la possibilità di almeno un post al mese... ;-))

Carlo Pescio said...

Il rischio c'e' ma ho il prossimo week-end dalla mia parte... Vedremo... :-)

vigj said...

si tutti pretendiamo la nostra pillola di saggezza...almeno mensile!

ci hai abituati male

Romano Scuri said...

Carissimo Carlo,

visto che gli impegni di questo periodo t'impediscono di dedicarci qualche riga, mi approprio del tuo spazio per un commento collaterale e mi scuso in anticipo per la poca attinenza al post originale, salvo il fatto che in qualche modo parlo di "pesantezza" ovvero di gravità.

Pochi giorni fa è stato rilasciato IE8 e siccome poco prima avevo letto, ahimé da fonti Microsoft, delle buone performance di questo nuovo browser, l'ho subito installato.

Caspiterina, ogni volta che lo avvio, da collegamento veloce oppure da qualche hyperlink, noto l'attesa e questo mi ha ormai indotto a pensare che non è per niente quella gran "scheggia" che volevano farmi credere.

Sarà pure più rapido del previsto una volta caricato, ma se il maggior uso che ne faccio è aprirlo e chiuderlo on demand, a cosa serve millantare benchmark favolosi quando ci mette una vita a partire?

Senza scadere nel flame sterile e di parte, qualcuno ha qualcosa da aggiungere / confutare ?

Grazie per l'ospitalità per questo informale dibattito.

Carlo Pescio said...

Mi pare che il caso umano :-) sia piu' interessante di quello tecnologico...

- chi te lo ha fatto fare di installare exploder 8?
- ma provare prima in una macchina virtuale...?
- se ci sta tanto a partire e dopo e' veloce, perche' non lo tieni aperto? :-)))))

Ne approfitto per linkare un post abbastanza divertente, ancorche' datato:

http://www.terminally-incoherent.com/blog/2006/08/19/what-does-your-browser-reveal-about-your-personality/

da quando l'ho letto ho iniziato a dire (oltre a exploder) anche "fried fox", ma per qualche motivo pochi lo trovano divertente.

Niente guerra dei browser tra i commenti, please.

Romano Scuri said...

Sperando che il tuo commento, Carlo, non induca gli altri a non dire la loro, aggiungo qualche risposta alle tue domande.

Costi quel che costi, salvo rarissimi casi, installo sulla postazione di lavoro tutte le novità che hanno attinenza in qualche modo con quello che faccio. Raramente faccio marcia indietro e solo se costretto. Cerco di adattarmi a quel che Microsoft propone soprattutto per mettermi nei panni degli utenti che dovranno fare altrettanto.

Non avevo una macchina virtuale a disposizione. Francamente non ne sento l'esigenza e preferisco in ogni caso provare direttamente nell'ambiente reale. Fuggo beta ed RC, però.

Non amo tenere sempre aperta un'applicazione. Quella che sopravvive più a lungo sul mio desktop è Explorer stabilmente puntata su c:\tmp. A proposito, quando anni fa un collega vide nella mia tmp una sottocartella tmp trattenne a stento le risate.

Che si dice in Internet a proposito di quelli che fatto di tmp la loro work-dir?

Romano Scuri said...

Ecco il link dell'articolo galeotto:

http://punto-informatico.it/2574496/PI/News/microsoft-ie8-viaggia-come-un-missile.aspx

Romano Scuri said...

Me la suono e me la canto da solo...

Da un po' di giorni sono passato a "Fried fox" che avevo installato da tempo, ma che usavo sporadicamente.

Per alcune cosette rimpiango IE7. Per la velocità è decisamente meglio di IE8.

Scuri Romano said...

Per quelle "cosette" ho trovato una valida alternativa e quindi azzero tutti i motivi per rimpiangere IE7.

Cosa si potrà mai dire ora riguardo a chi passa da "Exploder" a "Fried Fox"?

"Solo gli stupidi non cambiano opinione"? Troppo banale...

Romano Scuri said...

Pare che la ragione di tutto quel rallentamento sia dovuta all'immunizzazione operata da Spybot Search & Destroy.

Disattivandola si recupera performance.

Vedi http://groups.google.com/group/microsoft.public.internetexplorer.general/browse_frm/thread/3ef37656ce18f036/579478566ac1ee9b

Ma credo di tenermi FF ugualmente.

Carlo Pescio said...

Romano, non prendertela per la scarsa attenzione dedicata al tuo spunto, ma purtroppo era cosi' distante dagli obiettivi del blog, e cosi' prono a diventare uno sfogo di religioni varie, che ho preferito glissare.

Un punto sarebbe stato interessante: ho dato solo un'occhiata al benchmark che citavi, e mi pareva parecchio unimpressive.

Diciamo che moltissime variazioni mi parevano nell'ordine dell'errore sperimentale (tipo: 3.40 vs. 3.42 secondi), soprattutto in assenza di dettagli sul metodo di misura.

Questo poteva dare diversi spunti, sia su questioni tecnologiche che sociologiche. Magari un'altra volta :-).

Romano Scuri said...

Non me la sono presa per niente (non badare alla seriosità della mia foto :-)).

Il mio obiettivo era eventualmente sentire anche altri.

Se fosse stato per una discussione fra me e te soltanto potevamo sentirci via mail in privato.

Che poi non fosse attinente l'avevo scritto in premessa.

Grazie comunque per l'ospitalità.