Sunday, October 14, 2007 

Evolving (or rewriting) existing applications

I've been conspicuously absent from my blog in the last two weeks. Hectic life takes its toll :-), and it's not always possible to talk here about what I'm actually doing.
I'm often involved in very different activities, from weird bugs at the hardware/software interface, to coding tricky parts, to designing [small] application-specific frameworks, to making sense of nonsensical requirements. Recently, however, I've been helping a few customers make some rather fundamental decision about how to evolve (or rewrite) their applications.

Indeed, a significant subset of existing applications have been developed with now-obsolete technologies ("old" languages, framework, components, architectures), or even obsolete business concepts (e.g. a client-side application sold as a product, instead of a web application sold as a service).

Now, when you're planning the next generation of a successful application, you often end up trapped into a very natural, logical, linear thinking: we start from the core of the application, build a new/better/modern one, then we keep adding features till we have a complete application.
Sometimes, it's not even about starting at the core: you start with a large framework, and expect that you'll be able to build your applications in a snap (when the humongous framework is completed).

Now, this seems very logical, and if you look at it from a technology perspective, it makes a lot of sense. By dealing with the core first, you have the best chance to make a huge impact into the foundations, making them so much better. All those years on the market taught you a lot, so you know how to make the core better.
It's also easier this way: the new application will be entirely based on the new technology, from the bottom up. No need to mix old and new stuff.

As usual, a successful development strategy is completely context dependent! If your application is small, the natural strategy above is also the best overall strategy. In a relatively short time (since the application is small) you'll have a clean, brand-new application.
Unfortunately, the strategy does not scale at all to large applications. Let's see a few (well known, and often ignored) problems:

- The value delivery curve is pretty flat. Looks more like fig.1 in an old post of mine, as you can't really sell the new application till is finished.
People usually argue that by choosing the "right" core, they can start selling the core before the whole application has been ported. Yeah, sure, maybe in some alternative reality, but truth is, in many cases your existing customers won't downgrade to a less powerful, usually incompatible application (unless they're having major headaches from the old app).
New prospects won't be so exhilarated by a stripped-down core, either. Over the years, for a number of reasons, it' very likely that most innovation happened at the fringes of the old application, not at the core. You're now taking this stuff away for a potentially long time. Your old product will be competing with your new product, and guess what, lack of features tends to be rather visible.

- Although management may seem initially inclined to support your decision to rebuild everything from scratch, they won't stay silent as the market erodes. Soon they will (very reasonably) ask you to add some stuff to the existing application as well.
Now, by doing so, you'll slow down the development of the new application (resource contention) and you'll also create a backlog of features to be ported to the new application, once it is finished.

- All this conjures for very long development times. If you're working with intrinsically unstable technologies (like web applications), there is even a significant chance that your new application will be technologically obsolete before it gets to the market!

Let's try to model these (and a few more) issues using a diagram of effects



You may want to spend a little time looking at the different arrows, and especially at self-sustaining feedback loops. It's not hard to see that this is a recipe for having hard times. Yet companies routinely embark into this, because redoing the core is the most logical, most technologically sound thing to do. Unfortunately, it doesn't always make business sense
As usual, there are always other choices. As usual, they have their share of problems, and often requires better project management practices and skilled software designers. They also happen to be very context-dependent, as you have to find a better balance between your business, your current application, your new application.
Ok, time and space are up :-), I'll add a few details later.

Labels: , ,

Comments:
I'm back :-))

Per certi versi sembra la storia di Windows VISTA e... di tante nostre applicazioni.

C'è qualcuno che ci spinge inesorabilmente sempre verso nuove tecnologie e spesso la sensazione è che torni più comodo a lui che a noi.

La cultura del riciclo è una necessità quando si prende coscienza che l'energia è un bene limitato ed esauribile.

Col software se ne sente meno l'esigenza: basta un bel format ogni tanto...
 
Ciao Romano,
proprio in questi giorni pensavo che non ti si vedeva da un po'!

La pressione verso le nuove tecnologie arriva da tante fonti...

A volte arriva da chi produce il sistema operativo o i linguaggi, o da applicativi che impongono standard di fatto, o dai concorrenti. Questa a volte puo' essere un po' inopportuna, a volte puo' dare l'impressione di lavorare molto per avere in cambio poco o nulla (e magari non e' nemmeno un'impressione :-)).

Poi c'e' quella che deriva dalle nuove opportunita', ad es. passare ad una architettura web apre spesso nuovi interessanti scenari. Questa pressione puo' essere tecnologicamente difficile da gestire, ma a mio avviso ha un suo senso.

Poi c'e' quella interna, che deriva da una architettura ormai allo sfascio :-) o da codice impossibile da manutenere con efficienza. Questa spesso risponde ad esigenze concrete ma pone problemi tutt'altro che banali, ed e' uno dei casi piu' complicati da gestire bene, anche perche' non sempre la dirigenza capisce cosa si sta facendo...
 
Mi presento, sono un giovane (30enne) programmatore veneto importato in lombardia.
Proprio quando ho lasciato il veneto il mio datore di lavoro stava decidendo di migrare il suo gestionale verso .net da VB 6. Penso il primo codice l'abbia scritto con il framework 1.1 e adesso è in uscita il 3.5 e ancora non ha portato l'applicazione...
Dicevi sul fatto che l'applicazione potrebbe nascere già vecchia??? :-)
 
Un ulteriore lato negativo della vicenda e' che spesso, tutti presi dal porting tecnologico, non si ha ne' il tempo, ne' le energie (e spesso neppure la visione) per innovare in modo radicale l'applicativo nella sua interazione con l'utente, nel modo in cui affronta il dominio, nel modo in cui si risolvono i veri problemi.
Il problema e' diventato il porting, il resto non conta.

Ne accennavo anche in un mio vecchio articolo, When Past Solutions Cause Future Problems.
 
Post a Comment

<< Home