Wednesday, October 24, 2007 

More on evolving (or rewriting) existing applications

Just when I wanted to be more present in my blog, I had to survive the loss of about 200 GB of data. Nothing vital, but exactly for that reason, not routinely backed up either. Anyway, sometimes it's a relief to lose a little information :-).

In my previous post I've only scratched the surface of a large problem. If rewriting the application from the core is so dangerous (unless you can break the feedback loop in the diagram, which you can, but not for free), are we left with any viable option?

We all heard about refactoring in the last few years. Refactoring tools are getting better, to the point that you can actually trust them with your production code. However, refactoring can only bring you so far. You won't change a fat client into a web application by incremental, small scale refactoring. But careful refactoring is truly helpful when dealing with small scale problems. I've recently seen some C/C++ code full of comments, and guess what, the backtalk of those comments (see my "Listen to your tools and materials") is actually "please remove me and refactor the code instead". Refactoring is also hard when the code is strongly coupled with an outdated (or ill-structured) relational database, without any kind of insulation layer. So, refactoring is an interesting technique, and can often be applied in parallel with some more aggressive strategy, but is not really helpful when you need large scale changes.

An interesting strategy, that can be applied in more than a few cases, is the modular rewriting of applications. The concept is not new: you exploit (or improve by refactoring and then exploit) the existing architecture, by gradually replacing modules. With a little oversimplification, we could say that the real problem is which modules you want to replace first.

Again, this depends on a number of factors:

- do you have a different target architecture? If so, is there any module that you can replace in the existing system, and which will effectively move, almost unchanged, to the new architecture?

- are you just tired of maintenance problems? Then use quadrants to isolate the best candidates. Troubled modules with small size, or troubled modules with minimal coupling from the rest, should be your first candidates. Get as much value as you can, as soon as you can. Get momentum. We're not in the 80s anymore; flat value delivery curves are a recipe from project cancellation.

- are you "just" changing technology, or are you trying to innovate the application? Honestly, most companies can't innovate. Not by themselves, and quite often, not even with external help. They're prisoners of their own artifacts. They think of their problems in terms of the existing implementation. They will never, for instance, conceive a real web 2.0 application, because they can't think that way.
If you want to innovate the application, start with innovative features in mind. Design new modules, then bridge them with the existing system. While designing the bridge, push the envelope a little: can we erode a little of the existing system, an replace some subsystem with something more appropriate?
Doing so will move you toward an Incremental Funding project, which will gradually erode the existing system until it will make economic sense to scrap the rest.

- Note that this assumes that innovation is happening at the fringes of your system, not at the core. This is often true (see also "Beyond the core" by Chris Zook, Harvard Business School Press, for a business-oriented perspective), but sometimes, the real innovation requires a new core. Say you need a new core. Are you sure? Maybe you "just" need a new product, barely integrated with the existing system. Don't say no so soon. Play with the idea. Don't get into a self-fulfilling expectation by telling yourself that everything must be tightly integrated into a new core.

- Are you moving toward a truly better architecture, or just following a technology trend? Maybe your company was much less experienced when the current system was built. Still, are you sure the new core won't become brittle very soon? Do you really need a large core? Can't you decompose the system toward (e.g.) a loosely-coupled, service-oriented architecture, instead of a tightly-coupled, database-centric architecture (maybe with a web front end, big deal :-).

- can you apply some non-linear (a.k.a. lateral) thinking? Not familiar with lateral thinking? De Bono should be a required reading for software developers, and even more so for project managers and designers!

- is your new/target architecture aligned with your company strategy? If not, think twice!

OK, it's getting late again. See you soon, I hope, with some reflections on the concept of form (vs function) in the software realm.

Labels: , ,

Comments:
Citando la tua "intro" ad un precedente commento:

[curioso come i commenti talvolta prendano una loro strada secondaria rispetto al post :-))]

volevo rimembrare come nel 1985 (probabilmente qualcuno dei tuoi lettori non era ancora nato oppure emetteva i primi vagiti o al più si umettava le labbra di caldo latte materno :-)) nell'armeggiare con debug.com dell' MS-DOS 2.0, invece che scrivere in RAM corrompevo la FAT dell'HD del PC di lavoro. Poi ho imparato ad usare meglio debug.com e sono da allora diventato maniacale per i backup. Ne faccio uno (ovviamente parziale) ogni poche ore: uno zip veloce da sparare in rete su alcuni(!) PC. Poi temendo che la ditta possa andare a fuoco ne ho alcune copie (meno frequenti) nel caveau di un istituto bancario che qui non voglio rivelare per ovvie ragioni ;-)).

Io ho raccontato la mia. Perché non mi dite la vostra?
 
Spunto per un post

Questa dei backup è troppo interessante per lasciarla cadere nel vuoto. Perché Carlo non ci delizi con qualche aneddoto in proposito raccolto in tanti anni di professione a contatto con mille realtà aziendali?

Mai dato consulenze in merito?
 
(Ancora io sperando di essere un po' più in tema)

Il vecchio software, metaforicamente parlando, è come una vecchia signora. Se ha avuto bravi-buoni-belli genitori ne ha ereditato (mediamente è così) anche le caratteristiche. Passano gli anni, ma le qualità, estetiche e non, si vedono ancora. Spesso basta un poco di belletto, un abitino nuovo ed il figurone è assicurato. Se madre natura è stata invece inclemente (non lo è mai del tutto; spesso è solo questione d'indagare meglio, ma poi qualcosa di buono si trova sempre) state sicuri che il makeup non farà miracoli. Abbandonando la colorita immagine e tornando al software, in quest'ultimo caso tenetelo così se la cosa è ancora profittevole e/o ripartire ex novo con un altro prodotto.
 
Stravero, certe volte bisogna buttare tutto all'aria e pensare a una migrazione verso un altro prodotto, piu' che verso la nuova tecnologia. Quanto sarebbe bello fare una robina tutta nuova! :)
Il difficile e' proprio rendersene conto, concordo al 100%.

Io ho la fissa dei ladri: non mi basta fare il backup, voglio che nessun altro possa leggerlo. Quindi ho una procedura automatica che copia e cripta i dati. E se mi rubano il portatile? Niente paura: ho pure la home criptata, bastardi!
E se mi svaligiano la casa portando via i computer e i backup? Sono ancora salvo, ho una copia criptata dentro l'iPod!
Certo, resta poco da esultare se mi portano via tutta la gioielleria informatica...
 
Io tendo a fare una grossa distinzione tra cio' che in assenza di backup e' irrecuperabile e cio' che richiede solo una certa quantita' di tempo / sforzo per essere recuperato.

Per me e' irrecuperabile (ovviamente) qualunque cosa scriva o modifichi io. Per queste cose ho una certa cura.
Poi (come tutti credo) spesso quando trovo un documento o un software interessante in rete lo scarico e nel dubbio lo tengo. Questi ultimi tendo a non sottoporli a backup (ecco i famosi 200gb "persi" in buona parte), perche' ormai la quantita' di dati disponibili e' troppo ampia.

Per cio' che considero "importante/irrecuperabile" faccio backup frequenti su altri HD (ma non micro-backup ad alta frequenza come Romano), backup meno frequenti su DVD (che tengo geograficamente separati, un po' come fa Romano ma senza arrivare a metterli in banca :-), e poi da alcuni anni faccio un occasionale backup in un altro continente (via web), ovviamente zippando e criptando tutto quanto.

Storie di guerra ne avrei moltissime, non tanto perche' mi sia occupato in prima persona della vicenda (che tende ad avere risvolti piu' di system administration che di software engineering), quanto perche' spesso sono storie tragicomiche che si sentono narrare nelle aziende, o nelle quali ti trovi [tuo malgrado] coinvolto.
Purtroppo credo sia meglio tacere per preoteggere (o nascondere? :-) gli innocenti :-)
 
Post a Comment

<< Home