Extreme Enthusiasm

Siamo onesti… come programmatori, siamo costantemente tentati dalla Grande Riscrittura. “Se rifacessimo tutto in (Rails/Erlang/Wicket/whatever) …”. La realtà è che molto raramente la GR ha successo. Il vecchio codice contiene la conoscenza di tanti casi speciali che non abbiamo pensato (o che abbiamo dimenticato.) Il vecchio codice può essere brutto, ma chi ci dice che riscrivendolo saremo in grado di scrivere del codice significativamente migliore?

Se non siamo capaci di migliorare il codice giorno per giorno, pretendere di rifare tutto è velleitario. Prendete per esempio Derek Sivers, che due anni fa aveva annunciato in pompa magna l’imminente riscrittura del suo sito CDBaby da Php a Rails. Passati due anni, è ritornato a Php:

For 2 years, I thought Rails is genius, PHP is shit. Rails is powerful, PHP is crap. I was nearly killing my company in the name of blindly insisting Rails was the answer to all questions, timeframes be damned. But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much. Ruby is prettier. Rails has nice shortcuts. But no big shortcuts I can’t code-up myself in a day if needed. Looked at from a real practical point of view, I could do anything in PHP, and there were many business reasons to do so.

A questo proposito, Chad Fowler ha scritto una serie di articoli:

On a big system with a lot of customers, data migration can be a huge problem. Not only do we have to keep track of what gets migrated when, but we have to actually perform the migration at some point. The Big Bang sounds like a lovely idea until you get to the actual event, and you realize it’s kind of like preparing for a world title boxing match when you know it’s the first and last time you’ll ever compete. The processes and software you have to create, the attention you have to pay before you can create an event like this is often as consuming, complex, and potentially disastrous as the system development effort itself.

Ci vuole coraggio e umiltà per sporcarsi le mani con una pila di codice, diciamo, non propriamente elegante, e migliorarlo a piccoli passi, facendo refactoring, un pezzetto alla volta, senza mai “rompere” la funzionalità. Ma ci sono molto maggiori probabilità di successo!

This entry was posted on 25 September 2007 at 20:58 and is filed under Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.