Uma das minhas frases preferidas do Mark Twain diz “Se eu tivesse mais tempo, eu teria escrito menos”. Pois bem, é exatamente assim que eu encaro estas frases. Eu as vejo como verdadeiros insights, sínteses que dizem muito em poucas palavras. Aliás, falar com poucas palavras é o que o Twitter nos obriga a fazer e vira e mexe eu me pego tentando sintetizar uma idéia para compartilhar com os meus seguidores.

Estes dias descobri que poderia usar o favoritos do Twitter para ter um local único onde eu pudesse deixar as minhas frases favoritas de mim mesmo (minuto egocêntrico). O bom disso também é que estando nos favoritos as frases não se perdem como aconteceria na “time-line” do Twitter.

Na democracia da Web não tem porque colocar só coisas politicamente corretas. Por isso, na minha página de frases, também terá muita “abobrinha”.

Além disso, saiu o vencedor, ou melhor a vencedora do #imersaopromo.

A palestra foi gravada e assim que estiver disponível para download eu aviso já está disponível para download. Estou bastante ansioso para ver se consegui explicar bem as teses do Outbox. Afinal de contas, não é fácil falar sobre um tema tão peculiar para mais de 80 pessoas que prestigiaram a palestra (a sala nunca teve menos que 83, e chegou a ter 86 pessoas presentes).

UPDATE: Como pode ser visto no ultimo parágrafo deste post a palestra já está disponível para download.

Update: Descrição da Palestra
A cada ano que passa as tecnologias RIA ficam cada vez melhores. A cada ano que passa as pessoas dizem: “Agora sim! Vou fazer RIAs arrasadoras.” A cada ano que passa muitos não conseguem realizar este sonho. E, por fim, a cada ano que passa eu comprovo a minha tese: Não é como você implementa RIA, mas o modo que você as desenvolve que realmente importa. É sobre este MODO de desenvolver RIA que o Outbox trata. Concorde você ou não com as teses do Outbox, elas no mínimo irão te fazer pensar.

Desenvolvimento de Software, ao contrário de outras áreas como construção civil e arquitetura ainda é uma área relativamente nova. Nestas e em inúmeras outras áreas num primeiro instante não havia preocupação com a estética por uma questão de prioridade: prioriza-se a solução do problema essencial. Mas passada esta fase (que acredito que estamos chegando próximo no que diz respeito ao desenvolvimento de software) começa a pesar os fatores humanos, os fatores psicológicos, etc. Como diz Donald Norman “As coisas mais bonitas funcionam melhor”. Por que? Porque somos seres humanos e as coisas mais bonitas colocam nosso cérebro num estado muito mais propicio para uma determinada atividade: seja dirigir um carro, manusear um celular ou usar uma aplicação. Aqui entra uma outra tese minha junto com o TI-Centrismo Vs. Usuário-Centrismo que é o Trade-off com Foco no Valor Agregado.

Desenvolver softwares é também saber tomar as decisões certas com foco no todo e não em partes isoladas. E este conceito é sutil mas poderoso (e acredito que possui certa relação com a Gestalt). Daí a importância do Trade-off – que para quem não sabe é, basicamente, você fazer uma escolha entre um número de opções mas sempre sair perdendo umas coisas e ganhando outras. O grande problema do Trade-off em desenvolvimento do Software é que ele é influenciado pelo TI-Centrismo e não pelo valor agregado à experiência final do usuário como deveria ser.

Vejam exemplos:

A tabela acima deixa duas coisas bem claras:
1. Desenvolvimento sempre ganha
2. Estética sempre perde

Porém, dada a premissa de que a estética é importante porque somos seres humanos, será que, visando o produto final, visando a experiência como um todo, não seria interessante considerar eventualmente fazer um POG do Bem para oferecer uma melhor estética pois o usuário vai se sentir melhor com a sua aplicação? Será que você não deveria considerar que a Usabilidade não precisa ser a melhor do mundo, num dado contexto, para deixar o Designer Gráfico mais livre para trabalhar a estética? (sim, a Usabilidade cria restrições para o Designer Gráfico. Perguntem aos Designers se eles não se sentem um tanto limitados pelos Wireframes).

Quando eu falei da idéia do Trade-off com foco no valor agregado com o Luciano Lobato da DClick ele disse: mas todo Trade-off não deveria ser com foco no valor agregado? Sim, deveria, mas não é! Por quê? Porque na maioria das empresas cada tipo de profissional olha para o seu próprio umbigo e não para o software como produto final.

Que designers e programadores não se bicam não é novidade. Mas isto não é uma questão pessoal (pelo menos não no começo) . O problema, paradoxalmente, é que cada um de nós quer fazer o melhor trabalho possível. O Arquiteto da Informação quer oferecer a melhor usabilidade. O Programador quer fazer o melhor código. E o Designer quer fazer a aplicação mais bonita. Mas como cada um trabalha de forma independente, o que geralmente acontece é que um complica a vida do outro e ninguém sabe de fato o que é mais importante para a experiência final do usuário como um todo – chamo isto de Egocentrismo Funcional: o ego criado pela função que você exerce o impede de enxergar o que é melhor para o produto final. Desta forma, o programador se recusa a implementar algo muito complexo definido pelo arquiteto de informação – mas perde um baita tempo aplicando patterns desnecessários. O arquiteto de informação se recusa a mudar um wireframe sugerido pelo designer para deixar as coisas mais bonitas – e não pensa que talvez tal mudança agregue muito mais em estética do que perde em Usabilidade. Enfim, quando nenhum destes profissionais olham para o software como um todo, o que eles mais fazem é criar restrições que impactam negativamente o trabalho dos demais. E, além disso, quando se trata de tomar uma decisão isto não é deliberado e sim imposto por uma questão hierárquica (quem manda) ou pelo TI-Centrismo (Estética perde sempre. Usabilidade perde sempre.)

O POG do Bem nada mais é do que um exemplo de Trade-off com foco no valor agregado envolvendo programação e estética/usabilidade. Vamos agora a um exemplo de Usabilidade Vs. Estética.

Antigamente na DClick os arquitetos de informação definiam a usabilidade e depois restava ao Designer colorir os Wireframes. Certa vez uma alteração proposta pelo designer estava para ser recusada (como freqüentemente acontece) com argumentos dos arquitetos do tipo:
- Isso é ruim. O usuário terá que dar dois cliques no lugar de um.
Como eu estava de fora, observando o produto como um todo, eu perguntei:
- Mas espere um pouco! Com que freqüência ele terá que dar dois cliques?
- Não muita. – Responderam os arquitetos.
- Então isso é realmente um problema?
- Não, não é um problema grande!
- Então devemos priorizar a estética que no final das contas vai agregar mais à solução, visto que a perda de usabilidade neste caso é insignificante.

Suponha que na sua empresa o Arquiteto de Informação tenha mais “moral” que o designer, o que aconteceria? Suponha que o TI-Centrismo impere na sua empresa e que a mudança proposta pelo designer vai gerar certa complexidade, o que aconteceria?

Isto é Trade-off com foco no valor agregado! Você precisa abstrair e pensar num contexto maior: o produto final. Assim, não se deve tomar como regra a tabela de tabela de trade-off tradicional onde o desenvolvimento sempre ganha e a estética sempre perde. Não deixe esta tabela, que talvez esteja implicitamente arraigada na cultura da sua empresa, influenciar você!

O que temos que ter em mente é que nosso cérebro (novamente ele) não avalia nada isoladamente. Assim, o usuário falar se uma aplicação é boa depende do conjunto da obra. Por isso precisamos encontrar um equilíbrio entre a estética e a parte funcional. As vezes o programador deve deixar de fazer algo assim tão otimizado, pois talvez não seja necessário, para dedicar mais tempo na implementação de uma animação que agrega valor ou fazer bem um skin numa parte do software que o usuário passa a maior parte do tempo. As vezes você deve deixar de querer a melhor usabilidade do mundo se o problema de usabilidade não for assim tão grave e, por outro lado, isto deixa o designer livre para fazer algo realmente mais bonito. Por que? Porque é disso que o usuário vai lembrar quando ele pensar sobre o software. Não digo que ele vai lembrar APENAS da estética. Não digo que ele vai lembrar APENAS do funcional. Ele vai lembrar do conjunto da obra (Gestalt novamente). Ele vai lembrar das animações e isso o fará pensar que, junto com outras coisas, o software é bom. Ele vai lembrar do que ele pode fazer (funcionalidades) e isso o fará pensar que o software, em conjunto com a estética, é bom. É isto que é a experiência do usuário: o todo, não as partes isoladas. Então, refazendo a tabela de trade-off ela ficaria assim:

Isto é Trade-off com foco no valor agregado e não em paradgmas arraigados na cultura das organizações influenciados pelo TI-Centrismo ou por algum tipo de hierarquia burra.

Terrorista Juvenil A:
porra então tu assistia jaspion?

Terrorista Juvenil B:
eu ñ gostava mto do Jaspion… gostava mais dos Changeman
Ahamis… clássico!

Terrorista Juvenil A:
era legal também

Terrorista Juvenil B:
eu era o Change Dragon… meus outros primos eram o Pegasus e o Gryphon

Terrorista Juvenil A:
hahahah

Terrorista Juvenil B:
hahahaha
cara… mto engraçado estas coisas
eu tb brincava de Rambo no fundo de casa. tem bastante mato lá

Terrorista Juvenil A:
iiiiiii
O_o

Terrorista Juvenil B:
eu amarrava uma fita vermelha na cabeça, fazia arco e flecha com arame de guarda chuva, colocava pano com álcool na ponta da flecha e atirava no mato para ver pegando fogo
de vez em qdo eu tb pegava a espingarda de chumbinho do meu pai e ficava dando tiro nas vacas do vizinho

Terrorista Juvenil A:
haha
caralho
tu era foda

Terrorista Juvenil B:
q bom. eu aprontei bem

Terrorista Juvenil A:
eu uma vez comprei uma caixa de fogos e fiquei soltando no final da tarde na esquina da casa da minha vó, nos últimos fogos eu joguei dentro do galinheiro da vizinha
matei quase todas as galinhas
umas 20

Terrorista Juvenil B:
hahaha
mto loco
devia ter filmado

Terrorista Juvenil A:
eu fiz curso de eletrônica, aí eu ficava carregando capacitor e descarregando no pescoço de meus amigos

eu montava transmissor de FM, e ficava entrando na frequencia de tv ae entrava na hora do silvio santos e ficava saindo minha voz
os vizinhos me chamavam de terrorista

Terrorista Juvenil B:
haha

Terrorista Juvenil A:
eu falava “Vou te pegar…..! hahahhaha”

Terrorista Juvenil B:
mto boa

Terrorista Juvenil B:
uma vez eu estava brincando de soldado ou coisa do tipo. resolvi fazer uma cerca elétrica. então peguei um monte de arame, espalhei pela lavanderia da minha casa e liguei na tomada. levei um choque da porra. depois tive que pegar a vassoura para tirar o arame da tomada.

Terrorista Juvenil A:
hahaha

Terrorista Juvenil A:
eu montava transmissor e montei um bem pequeno, e coloquei no banheiro das meninas pra escutar elas, ae eu levava um walkman pra escutar. Fui expulso da sexta serie minha primeira vez
eu fiz a sexta serie 3x, e não passava, aí resolvi largar mão

Terrorista Juvenil B:
hahaha
caraca… vc foi expulso?!!
hahaha

Terrorista Juvenil B:
eu repeti a quinta série
na época eu treinava karatê e gostava de ficar arrumando briga na escola

Terrorista Juvenil A:
hahaha
da outra vez que fui expulso eu quebrei o braço do anderson

Terrorista Juvenil B:
kkkk
putz… a gente tem q ter estas conversar num happy hour
ia ser hilário

Terrorista Juvenil A:
porra bicho, o anderson ficava me zuando
ficava me chamando de ^%$##$

Terrorista Juvenil B:
hahaha

Terrorista Juvenil B:
a melhor: eu ficava p da vida qdo eu comprava salgadinho e vinha aquele monte de moleque da rua ficar pedindo. uma vez eu resolvi aprontar para nunca mais ninguém me pedir. comprei um cebolitos e coloquei um monte de sal de fruta. ficava igualzinho sal. aí veio aquele monte de moleque… fulano, fulano me dá um pouco. opa, pode pegar…. em dois minutos estavam todos com a boca espumando.

Terrorista Juvenil B:
outra vez apareceu um pasta de dente lá em casa q parecia recheio daqueles doces de padaria. eu peguei um pão, enchi de pasta de dente e saí na rua. aí veio a molecada novamente. eu distribui a vontade. em segundos os caras estavam cuspindo no chão. acho q depois destes dois episódios ninguém nunca mais me pediu nada

Terrorista Juvenil A:
cara tu era terrorista

Terrorista Juvenil B:
haha. nunca matei ninguém. só dava coisa ruim pros caras comer. hahaha

Terrorista Juvenil A:
hahaha

Terrorista Juvenil B:
é mto loco mesmo. mas acho q de tanto aprontar qdo criança acabei me tornando um adulto criativo. eu gostava de inventar. queria ser inventor quando criança. meu maior fracasso foi a maquina de matar mosquito q era basicamente uma madeira com dois pregos, um elástico e um clips. vc tinha q tentar acertar o clips no mosquito. nunca matei nenhum. mas acho que hoje eu viajo no Flex por causa disso. hehehe

Terrorista Juvenil A:
hahahah

Terrorista Juvenil B:
vamos continuar esta conversa qq dia desses pessoalmente. vai ser hilário. eu vou contar o q eu fiz para ñ ser seqüestrado por ET. eu morria de medo disso

Terrorista Juvenil A:
hahahah
falow

Bem, o Terrorista Juvenil A é o Carlos Eduardo e o Terrorista Juvenil B é o Beck Novaes. Sim, foi o Carlos que matou 20 galinhas e o Beck que deixou o boca dos garotos da rua cheia de espuma com sal de fruta. O que vocês acabaram de ler foi uma conversa que tivemos no Talk.

Mas e você? Também é um terrorista juvenil que trabalha com Flex? Conte-nos qual foi sua maior travessura.

Algo parecido acontece com os usuários em minha opinião.

“Saber o que quer” é diferente de “saber o que precisa”. O usuário sabe o que quer, mas você NÃO DEVE fazer o que ele quer, você deve fazer o que ele precisa!

O que usuário quer num primeiro momento vai deixá-lo com a falsa impressão que o projeto está indo bem. Mas depois de um tempo ele verá que não é bem assim. Depois de um tempo ele vai querer mudar para o que ele precisava mas não sabia.

O problema de desenvolver com foco no que o usuário quer é que isso é baseado em desejo e como tal é rotineiramente distorcido pelas impressões. Desenvolver baseado no desejo dos usuários o leva a assumir premissas e criar restrições erradas para o desenvolvimento do Software. Isso complicará o seu projeto e provavelmente levará a resultados pouco satisfatórios. O problema é que o usuário vai culpar você por isso e nem vai lembrar das informações imprecisas que ele lhe passou sobre o que ele desejava.

Sim, o usuário não vai lhe dizer o que ele precisa porque ele não sabe! Pior, por sua natureza, entender o que o usuário realmente precisa é mais “arte” do que ciência. Você precisa saber lidar com pessoas. Você precisa saber que o usuário é um ser humano como outro qualquer e que está muito confuso sobre o seu problema. O usuário define seus softwares tal como um casal apaixonado olha para o céu e vê cachorrinhos nas nuvens. E ele faz isso porque o nosso cérebro funciona assim: por associações. É por isso que vira e mexe ele olha outro software que não tem nada a ver com o seu problema e diz: eu preciso disso! Então você começa a desenvolver e aprende a duras penas que não era nada daquilo… e você muda um pouco aqui, muda um pouco ali e quando vê já está com um Software Frankenstein nas mãos.

O usuário define seus softwares tal como um casal apaixonado olha para o céu e vê cachorrinhos nas nuvens.

É neste ponto que você deve deve ter a “astúcia” de abstrair os desejos do usuário, considerar as informações relevantes sobre o que ele está lhe falando e propor soluções que, pelo seu conhecimento, devem agregar mais valor do que aquilo que o usuário pensava antes. E você terá que saber argumentar com ele sobre esta “nova” solução. Porém, compre mesmo esta briga! Não desista tão facilmente de convencê-lo a “fazer do seu jeito”. Demonstre confiança no que você esta falando. Baseie-se em estudos, fatos, exemplos. Conquiste a confiança dele antes de qualquer coisa. Não existe receita de bolo para isso e eu acredito que é por isso que estes templates de Casos de Uso ou qualquer outra coisa do tipo falham. Não me refiro ao artefato em si, mas o modo como ele é concebido: geralmente um processo burocrático, formal, nada humano e extremamente chato!

Finalmente, quando você consegue fazer O QUE O USUÁRIO PRECISA pode até ser que exista algum atrito no inicio – porque ele ainda não tem certeza que precisa daquilo. Mas conforme o tempo passa ele entenderá melhor porque as coisas estão tomando o rumo que estão tomando – ele aprende junto com você o real problema. E eis que o usuário passa a querer o que ele precisa e é aí que está a chave do sucesso.

Nota: Este post é uma “extensão” do comentário que fiz neste outro post.

O TI-Centrismo prega que TI é o centro do Universo. Desta forma, muitas das decisões tomadas no ciclo de vida de desenvolvimento do Software visam “proteger” TI.
- “Não pudemos mudar isso, é padrão de TI!” = TI-Centrismo
- “Não dá para fazer assim, o banco não permite” = TI-Centrismo
- “Não vou deixar meu código feio assim. Deixa essa animação pra lá” = TI-Centrismo
- “Vamos fazer o Café com Leite, senão vai dar muito trabalho.” = TI-Centrismo

Precisamos mudar isso! Precisamos deixar o TI-Centrismo e adotar o Usuário-Centrismo. Pode não parecer mais isso muda muita coisa.

Programadores odeiam código feio. Por outro lado a parte estética da aplicação e as animações são sempre deixados para o final. O problema? Bem, muitas vezes perde-se muito tempo tentando fazer aquela arquitetura super hiper robusta com o super hiper design pattern onde não precisa.

Mas por que a estética, incluindo animação é importante? Porque isso deixa o usuário num estado mental muito melhor. Isso faz com que o usuário:

1. Perdoe erros mais facilmente
2. Tenha maior pré-disposição para aprender a mexer na aplicação

Fizeram uma experiência com dois caixas eletrônicos idênticos em termos de usabilidade e implementação. Um bonito e outro feio. O Caixa mais bonito teve uma avaliação muito melhor do que o caixa mais feio. No Caixa mais feio as pessoas reclamaram muito mais dos erros (propositais) do que no caixa mais bonito. Uma coisa é o usuário bater o olho numa coisa bonita e falar: “Uau… que legal isso. Bem, agora deixa eu ver como eu uso!”. Outra coisa é ele falar “Nossa! Que coisa medonha, como eu uso isso?” O estado mental é tudo. A motivação é tudo. E coisas feias definitivamente desmotivam.

Quando abandonamos o TI-Centrismo e adotamos o Usuário-Centrismo nossa percepção muda. Eu prefiro perder tempo fazendo uma animação que vai agregar mais valor à experiência do usuário do que aplicando aquele super ultra design pattern que li no ultimo livro que ostento na minha estante e que só vai servir para eu exercitar o que aprendi. E isso tem a ver com outra coisa que eu chamo de Tradeoff com foco no valor agregado (assunto para um outro post).

Em muitos casos o TI-Centrismo é como uma religião. Só espero não ser condenado como Galilei Galilei por tentar mostrar que o centro do Universo não é o que os devotos pensam.

Ao adotar o Usuário-Centrismo comecei a me perguntar se os POGs que tanto incomodam os programadores que pregam boas práticas em 100% do Software (TI-Centrismo) são realmente um mal em todos os contextos. Eu ousaria dizer que, no Usuário-Centrismo existe o POG do Mal e o POG do Bem. Imagine que você precisa implementar uma animação em Flex e que, como um bom programador, você tentou fazer da melhor forma possível. Mas não teve jeito! Você vai ter que colocar um Timer para fazer funcionar perfeito (típico POG para resolver problemas de tempo em animações em Flex). Mas você é um programador “bonzão”. Você jamais vai fazer este POG. Então você se recusa. Afinal de contas, para quê animação, não é mesmo? Mas a pergunta é: Tal animação vai agregar valor à experiência do usuário? Sim! O POG vai ser fonte potencial de problemas? Não! O POG vai ser difícil dos programadores entender? Não (nada que um comentário simples não resolva). Então, por que que eu vou me recusar de fazer algo que mais agrega à experiência do usuário do que, de fato, prejudica TI? Porque eu sou adepto do TI-Centrismo. Eu não faço software para o usuário, eu faço para mim. Para o meu ego.

Eu quis manter o diagrama acima simples e por isso o fiz “incompleto”. No caso da complexidade, por exemplo, mesmo que POG pareça “comprometer a complexidade” é preciso colocar isto na balança pois também acredito que não há mal algum em algo complexo, encapsulado e que pouco vai ser mexido. Mais um vez, é o que eu chamo de Tradeoff com foco no valor agregado.

O TI-Centrimo começa nas Universidades ou quando o iniciante está aprendendo a programar. Nesta época, sem experiência e capacidade para julgar, os professores colocam na cabeça das pessoas que a performance do sistema é um problema independente do contexto. Em outras palavras, aprende-se que sempre se deve otimizar um simples “for” (tentar transformar 200 iterações em 100 por exemplo). Aprende-se que se deve preocupar com a performance desde o início. Mas o que não é dito é que código otimizado é mais complexo. O que não é dito é que o gargalo de performance corresponde a um percentual muito pequeno do código do seu software. O que não e dito é que você geralmente não sabe onde está este gargalo e que no final das contas você vai perder muito tempo tentando otimizar código onde não é preciso, adicionando complexidade ao seu código e deixando de fazer outras coisas que agregam mais valor. Isto é TI-Centrismo!

O TI-Centrismo cria tantas restrições para se fazer um bom trabalho que Software de qualidade do ponto de vista do usuário é praticamente impossível. O TI-Centrismo é respaldado (entre outras coisas) pela alienação do programador. Softwares existem porque alguém precisa usar. Este alguém é o usuário. Ele é a razão do software existir. Mas muitos programadores esquecem disto e o seu código passa a ter uma razão de existir em si. Este programador aplica Design Pattern porque ele gosta. Ele aplica boas práticas porque ele gosta. Ele faz código otimizado porque ele gosta. Mas ele não gosta de perder tempo com animação – que as vezes é o que vai agregar valor à experiência final.

Você pode adotar o Usuário-Centrismo e continuar apreciando código bonito e de qualidade. A diferença é que o Usuário-Centrismo vai lhe fazer pensar que o seu código tem que ser bom para lhe permitir fazer um Software cada vez melhor não para você, mas sim para o usuário.

O que jamais podemos esquecer é que fazemos softwares para os usuários. Então ele deveria ser o centro do universo, e não TI.

Ou, pela imagem abaixo, pode ver o feedback do pessoal no final do curso.

Aqui os meus sinceros agradecimentos às pessoas que acordaram cedo quatro sábados seguidos para participar do curso, souberam me dar umas dicas do rumo e do ritmo que o curso estava tendo na hora certa, e me recompensaram com este feedback final tão positivo. Sensação de dever cumprido.

Pois bem, sabemos que o código não vai ficar bom em 100% das partes do Software. Então, a chave é fazer o código bem feito onde ele precisa ser bem feito, ou seja, nas Partes Relevantes. O problema? No início de todo projeto sempre há aquela preocupação em fazer tudo genérico, bonito, organizado, etc. E justamente neste momento sabemos muito pouco sobre as Partes Relevantes. Como resultado, acabamos perdendo muito tempo implementando coisas bonitas e genéricas onde não precisava e isso toma justamente o tempo que deveríamos dedicar à… quem? quem? às Partes Relevantes do Software.

Então um outro programador assume o nosso código e, obvimante, ele terá que mexer…bem, você sabe aonde. E não importa o quanto seu código está bom nas outras partes pois ele não vai nem entrar nelas. Você teve sim a preocupação em fazer um código bom, mas fez isso no lugar errado pois não sobrou tempo para fazer no lugar certo. Por isso, o outro programador vai achar que o seu código é uma merda pois ele sabe do código bom que ele é capaz de fazer (mesmo que ele o faça onde não precisa) e está vendo a parte do seu código que até você tem vergonha. Então ele vai ficar dando palpites no seu código – mas agora é fácil, pois neste momento as Partes Relevantes são evidentes. Até que um dia ele precisa implementar um conjunto de funcionalidades novas e o ciclo se repete (outro assume, critica, faz bem onde não precisava e mal onde precisava). E assim continuamos achando sempre que o nosso código é melhor do que o dos outros pois sempre analisamos no final, numa atividade onde uma das coisas mais importantes é entender realmente o que precisa ser feito.

Mas eu desconfio que este ciclo poderia ser quebrado se a Refatoração fosse levada a sério. Eu disse: LEVADA A SÉRIO! Não falo do mito da refatoração no final do projeto. Falo em Refatorar sempre que adicionar uma nova funcionalidade, por menor que seja. Falo em adaptar o código existente para que esta nova funcionalidade se encaixe como uma luva sem a necessidade de “ifs” para tratar casos não previstos. Se o caso não foi previsto eu não vou colocar um “if” (ou violar os princípios de OOP) para que funcione, eu vou mudar o código existente para que ela se encaixe como se tivesse sido prevista desde o início.

Quando você Refatora corretamente o código fica melhor com o tempo pois a cada nova funcionalidade você entende melhor o que precisa fazer. A cada funcionalidade nova você entende melhor quais são as Partes Relevantes. Por outro lado, quando você não Refatora o código fica ruim com o tempo pois você está ignorando o que está aprendendo de novo sobre o que precisa de fato ser feito.