Wednesday, April 11, 2007 

Design for Outsourcing

Countless pages have been devoted, over the years, to explain why design is useful. Countless pages have been devoted to explain how to design for extendability and reusability. Significantly less on how to design for testability, although the agile camp contributed some, under the Test Driven Design chapter. Again, countless pages have been spent in debates over the up-front Vs. as-you-go design approaches.
What is often missing in most debates is context: quite often, there is some truth in both sides, that is, given the proper context, a given approach might be better suited. It's usually the (faulty) assumption that some approach can always be successfully adopted that makes so many debates futile.

Design should be therefore discussed in-context. Context includes the technological issues, the market issues, the organizational issues, the human issues, and so on. For instance, a recurring problem among many companies is:

- they have more work to do that they can possibly do.

- they are reluctant to hire new developers; even if they do, they believe it will take a significant time to get the new hires up to speed.

- they are reluctant to outsource some developments. The usual complaint is that just explaining the problem, following progress, training some external personnel on the business issues is more effort than just doing the damn thing.

We all know how it ends:

- considerable friction between management and (disgruntled) developers.

- delayed or canceled projects, possibly some lost market opportunity.

- little or nothing is learnt from the experience, so next time it's the same game all around.

Now, this is not a technical issue. It's an organizational issue, and as such, it can't be completely solved at the technical level. However, it's a relatively common context, and as designers, we should take this into serious consideration.

In an old post, I discussed how to use quadrants to divide activities, to find some tasks better suited to offshoring (in a particular context, where the offshore team didn't have much domain expertise). The basic idea was that some tasks (technology oriented, stable requirements) where better suited to offshoring.

Of course, offshoring and outsourcing are quite different matters. However, there are many similarities that might be worth exploring. Indeed, for sake of brevity, that post didn't mention two important issues:

- technology Vs. domain is just a simplified view of strongly - loose coupled.

- tasks are a consequence of design; we can change the design to move some critical mass of tasks into a different quadrant.

Let's review the two concepts:

- In that particular context, what was missing offshore was domain knowledge, not programming knowledge. Transferring domain knowledge would have bogged us down for quite some time. However, this is just a (real-world) example. In other cases, transferring knowledge about a huge database schema would slow you down. Or about a particular middleware you're using. Or about a specific framework (which is why, by the way, I don't like invasive frameworks), And so on. Knowledge must be transferred because it is not isolated (not enough information hiding, not enough separation of concerns, and so on) or because it has not yet been encoded into an executable form (that is, it's just in your head, but not yet in code). The tasks better suited to outsourcing (or to offshoring) are obviously those with the minimum coupling, therefore with the minimum need for knowledge transfer.

- Tasks are a consequence of design. Design is under our control: we decide where the effort must go (extendability, reusability, or... outsourceability :-). We can change the structure, the approach, even twist some requirements (c'mon: we always do) to increase the number of loosely-coupled components. Of course, this is not going to be free: you'll have to compromise elsewhere (performances, observability, etc), but as I said, design is contextual, we don't make choices in a void (this, again, is why I don't like frameworks that have made too many choices for me).

Note that I'm talking about outsourcing tasks (which most likely, translates into outsourcing components) as opposed to outsourcing applications. There would be a lot to say about this, under the perspective of risk management, but I'll save that for another post. Suffice to say that there are certainly applications that can't be economically outsourced, but which have significant components that can be economically outsourced.

Bottom line: we can gradually break the loop above, by designing software in a different way, so as to move more tasks into the outsourcing sector (loose-coupled, stable requirements). This requires, in my opinion, some degree of up-front design. Of course, I'm aware that up-front design has been given a rough time by more than a few agilist. But it's also quite obvious that most of the critics made an implicit assumption upfront = big, extensibility and reuse oriented. Which is quite a narrow view of design.

So, next time you find yourself saying "nobody can help us with this", try a different angle: can we change the structure so that somebody can help us on this? This may be all you need to get out of an otherwise deadly self-fulfilling expectation.

P.S.
for the paranoids :-) out there: no, I'm not in the outsourcing business :-)). And yes, I've helped quite a few people to reshape their design to make outsourcing easier :-).

Labels: ,

Comments:
C'e' qualcosa che non mi quadra.

Il dominio: puo' essere piu' o meno complesso da imparare.
Supponiamo che sia complesso: il training sul dominio puo' superare alla grande il training sul design e/o codice. Quindi vedo poche possibilita' di outsourcing.
Supponiamo che sia semplice (o gia' trasferito all'esterno): ci si concentra su un design che spinga sul "loose-coupled, stable requirements".

Il design: se e' ben fatto, chiaro, semplice, allora anche gli esterni possono metterci le mani.
Se, al contrario, e' un paciugo, come dici tu e' meglio sistemarlo prima all'interno, tenendo in mente che altri ci dovranno mettere le mani.

Percio', se tutto fila, l'outsourcing diventa possibile e conveniente quando il dominio e' semplice o gia' trasferito e il design e' ben fatto. Bella scoperta... :-)
Mi puoi fare qualche esempio di design studiato per agevolare l'outsourcing? Non riesco a immaginare la parte pratica del tuo discorso.

Su tutto, una immensa verita': "explaining the problem, following progress, training some external personnel on the business issues is more effort than just doing the damn thing"... eeeeesatto!!! :-)
 
Ultimamente ho preso a chiamare la ricerca sul come orientare il design meta-design. Credo ci sia lo stesso rappoto tra design e meta-design che tra design e programmazione, con la stessa complessa compartecipazione che non è certo ad una sola direzione. Una cosa è certa pero'... il vero "guadagno" a livello di tempo impiegato, di qualità finale o più in generale di valore si può conquistare solo con un attento meta-design. Esattamente come nel caso di un algoritmo di ordinamento la differenza più significativa la fa la sua complessità, non certo il dettaglio della sua implementazione.
 
Citrullo, al solito mi offri uno spunto interessante per chiarire meglio alcuni aspetti.

Il dominio: puo' essere piu' o meno complesso da imparare.
Supponiamo che sia complesso: il training sul dominio puo' superare alla grande il training sul design e/o codice. Quindi vedo poche possibilita' di outsourcing.


Citazione: "perche' non stai pensando quadrimensionalmente" :-).
Piu' seriamente (per quanto mi e' possibile), proviamo con un paio di esempi concreti.

Iniziamo con un caso in cui non ho modificato il design per rendere piu' semplice l'outsourcing (perche' non era un obiettivo), ma dove avrei potuto farlo.
Recentemente rivedevo, insieme ad un gruppo di sviluppatori, il design di un applicativo per la pianificazione della produzione (in realta' una verticalizzazione). Il dominio non e' necessariamente "complesso", anche se la verita' e' che tutti i domini sono "complessi" quando si entra realmente nei dettagli (esiste una diffusa tendenza a credere che alcuni domini, tipicamente matematico / scientifici, siano piu' complessi; in realta' hanno le loro complessita' e le loro semplicita' rispetto ad altri, dove magari la mancanza di concetti formali complica molto piu' che dover conoscere le equazioni differenziali).
In ogni caso, il design era totalmente basato su concetti del dominio. Questo e' generalmente considerato un buon segno, perche' quando il design (solution domain) e' vicino al problem domain, tutta una serie di ragionamenti e di discussioni diventano piu' semplici. Le persone coinvolte avevano [ormai] dimestichezza con il dominio, e non c'era alcun motivo di "rompere" questa caratteristica positiva (c'erano invece altri interventi da fare, soprattutto per sfruttare meglio il polimorfismo e razionalizzare alcuni aspetti algoritmici).
Detto questo, se avessimo voluto dare in outsourcing una parte significativa del progetto, pensando "linearmente" avremmo dovuto trasferire tutta una serie di nozioni sul dominio. Va detto che i requisiti erano ragionevolmente stabili, non ci era difficile capire dove introdurre alcuni hot-spot di estendibilita', e quindi se non avessimo avuto un cosi' forte accoppiamento sul dominio saremmo stati nel quadrante giusto.
Tuttavia l'accoppiamento sul dominio e' una caratteristica che io posso alterare a livello di design. Nel caso specifico, se avessi voluto, avrei potuto scorporare una grossa porzione, modellarla in modo totalmente astratto (in termini di grafi e di operazioni su di essi), introdurre alcuni punti di disaccoppiamento sotto i quali il team interno avrebbe "pluggato" le classi domain-dependent, e via. Avrei disaccoppiato dal dominio e reso molto piu' semplice l'outsourcing.
Nota che non l'ho fatto perche' il design e' sempre contestuale: l'astrazione, contrariamente a quanto a volte insegnano a scuola :-), non e' di per se' un valore. Anzi, le persone coinvolte avrebbero fatto di gran lunga piu' fatica a ragionare in termini astratti che in termini concreti. Ma era una possibilita' a portata di mano.

Altro esempio, dove invece ho colto l'opportunita' (in ottica offshoring e non outsourcing, ma non cambia molto in questo caso). In un post precedente citavo un lavoro su Basilea 2. Qui il design "immediato" avrebbe portato ad alcune classi molto vicine al dominio del problema, facili da capire per chi conosceva bene il dominio, ma individualmente piuttosto "ricche" di comportamento decisamente domain-specific. Comunicare bene queste cose sarebbe stato un incubo.
Il mio design era, come accennavo, molto distante dal domain problem. Molto basato su meta-informazioni definite dal team piu' esperto sul dominio, spezzava molte classi di cui sopra in piccoli predicati, piccoli elementi di storicizzazione, ecc ecc, ognuno dei quali aveva un debolissimo accoppiamento con il dominio.

Al solito, e' solo questione di voler realmente fare qualcosa, ed il modo si trova. L'obiettivo finale, ovviamente, deve essere proprio di falsificare quella "verita'" sotto cui hai scritto "eeeeesatto", altrimenti, non ci siamo :-).
 
Anonimo: assolutamente d'accordo. Quando dico che il design deve essere contestuale, significa proprio che mi servono delle meta-regole per scegliere tra le regole, ecc ecc.

In realta', in questo senso il meta-design mi pare una componente necessaria (quasi inscindibile?) della leadership tecnica, ed in senso ancora piu' generale di un buon project management (ovvero di una gestione del progetto che capisce cosa sta gestendo, ovverossia le dinamiche dello sviluppo software).
 
This post has been removed by a blog administrator.
 
Post a Comment

<< Home