Simplesmente complexo 

Jun/10
29

Como sabem eu venho de uma forma√ß√£o¬†acad√™mica em ci√™ncias naturais – em f√≠sica – onde as coisas t√™m que fazer sentido real mesmo quando trabalhamos com coisas t√£o abstratas quanto uma fun√ß√£o de onda da f√≠sica qu√Ęntica. ¬†Pese embora a grande onda mitol√≥gica que rodeia a fisica qu√Ęntica ela n√£o √© baseada em magia ou achismo, ela √© baseada numa estrutura matem√°tica. Quando descobri a minha voca√ß√£o para a cria√ß√£o de software tive que¬†rapidamente¬†me por a par do que estava acontecendo neste mundo. E aqui, de um jeito pr√°tico e n√£o acad√™mico. Durante os meus primeiros trabalhos com software n√£o existia exatamente um m√©todo a seguir, existia um fluxo de demanda. Mas esses primeiros exemplos me mostraram que n√£o era¬†poss√≠vel¬†fazer software assumindo que √© algo mec√Ęnico e reativo. ¬†Tendo forma√ß√£o acad√™mica me voltei para os livros – o que √© dizer muito, porque nunca antes lhes tinha dado muito valor, mas quando entramos num campo diferente daquele que fomos educados e no qual sabemos intuitivamente navegar, √© bom ter refer√™ncias. A raz√£o para isso √© que n√£o poderia cair nos mesmos mitos que as pessoas j√° no ramo tinham ca√≠do, da mesma forma que o ing√™nuo – coloque aqui uma profiss√£o – cai no mito da¬†mec√Ęnica¬†qu√Ęntica “m√°gica”. Eu nunca fui de idolatrar autores, ou memorizar livros, ou saber (re)citar passagens. A¬†experi√™ncia¬†me mostrou que quem entende os conceitos n√£o precisa dessas coisas, mas li bastante para me tornar um programador java, tirar minha certifica√ß√£o, mas o que mais me atrapalhava era n√£o existir um m√©todo para criar software. Em java, temos os principios de OO para seguir como os principios SOLID. Em f√≠sica, temos o m√©todo¬†cient√≠fico¬†como base e v√°rias pr√°ticas de laborat√≥rio que nos guiam. Entretanto, em gerenciamento de projetos de software me impressionava que tal coisa n√£o existisse.

Fiz quest√£o de fazer um curso n√£o program√°tico na finada Sun exatamente para descobrir esse outro lado. No curso que era guiado principalmente pelo Processo Unificado (Unified Process, UP) era levantada a lebre de um tal de XP. Eu tinha tido contato com o XP ainda quando fazia meu est√°gio em f√≠sica. Afinal a f√≠sica pr√°tica passa pelo processamento de sinal, e este passa por usar computadores. ¬†Com o passar do tempo as pr√°ticas que observava na realidade n√£o batiam com o que os livros diziam e o insucesso de v√°rios projetos me fez entender que para entrar no mundo do software antes de saber programar √© preciso saber escolher entre¬†filosofias¬†de desenvolvimento. ¬†O Rational UP da ¬†Rational Rose, depois IBM no tempo do CASE lan√ßou o mote. A ideia era ter ferramentas onde especificar o software, apertar um bot√£o e simplesmente teriamos um software funcionando. N√£o resulta. Ferramentas ainda s√£o burras e precisam de algu√©m que as saiba usar. ¬†Algu√©m muito esperto consegue vender esta ideia imbecil de que software pode gerar software automaticamente. Ainda hoje existem tentativas de enganar os pac√≥vios com esta artimanha. Repare que o engano adv√©m de quem compra e n√£o de quem vende. √Č quem compra que √© muito desonesto, tapado, analfabeto ou burro para n√£o entender a engana√ß√£o.

Apenas pessoas sabem fazer software e existe uma razão muito simples para isso: fazer software é um processo criativo. Criativo aqui significa tanto ser um processo onde se cria algo, como um processo em que se precisa ter imaginação. E as máquinas não têm isso ainda.

Ent√£o por que √© t√£o¬†dif√≠cil¬†fazer software? Fazer software n√£o √© dificil. O que √©¬†dif√≠cil¬†√© fazer software que algu√©m compre e atenda a uma demanda, a uma necessidade. Para qualquer produto comercial existem duas formas de demanda. Ou quem quer comprar, compra o produto j√° pronto que o produtor j√° criou antecipadamente (retail sell – venda a varejo) ou o interessado chega junto ao produtor e pede que seja feito um produto com certas caracter√≠sticas (tailored sell – venda sob medida). Na primeira categorias podemos encontrar muitos produtos como p√£o, fruta, vinho, carros, casas – e inclusive software – e no segundo podemos encontrar produtos como roupa (de¬†alfaiataria), carros (Rolls Royce), avi√Ķes e tamb√©m software. Qual √© a diferen√ßa? Volume. ¬†A primeira categoria ganha em vender barato e muito. A segunda em vender caro e pouco. Ambos t√™m o seu quinh√£o de mercado. Atenhamo-nos apenas ao software feito sob medida (sob demanda – on demand, como tamb√©m √© chamado) para o resto da conversa.

Em tudo o que é feito sob medida, e também num software, precisamos saber como o cliente deseja que seja o resultado final. Afinal o resultado final servirá a ele e apenas a ele. Tal como um casaco ou um terno que serve apenas a uma pessoa. Pode até ser que sirva para outros, mas nunca sem ajustes. Precisamos então saber quais são os requisitos. Requisito é um conceito muito importante neste tipo de produto, porque é à medida dele que será feito o produto final.

Um outro fator na equa√ß√£o √© como ser√° feito o produto. A tecnologia que ser√° usada para realizar o produto afeta o pre√ßo, a qualidade, a durabilidade, e at√© o¬†aspecto¬†e usabilidade do produto. ¬†Existem tecidos espec√≠ficos para certos tipos de roupa e¬†circunst√Ęncias¬†espec√≠ficas. Existem raz√Ķes¬†t√©cnicas¬†de¬†porque¬†o mesmo casaco precisa ser de algod√£o em umas regi√Ķes e de l√£ em outras. ¬†Se formos fazer um produto que nunca¬†ningu√©m¬†fez antes ou poucos tentaram e tenhamos que experimentar diferentes tecnologias ser√° diferente daquele que utiliza uma tecnologia j√° muito entendida e¬†aperfei√ßoada.

Pondo estas duas forças num gráfico obtemos um cenários mais ou menos como o mostrado na figura a seguir.

Complexidade vs Tecnologia

Na zona verde estão os produtos menos complexos, os mais complexos na zona vermelha. Repare que o software é algo complexo.

Muita gente – gente demais, na minha opini√£o – adora comparar “fazer software” com “fazer casas, carros e avi√Ķes”. N√£o, essas coisas n√£o s√£o nem de longe t√£o complexas. Por qu√™? Porque os¬†requisitos¬†s√£o muito bem conhecidos e a¬†tecnologia¬†tamb√©m. N√£o h√° surpresas – tijolo √© tijolo e metal √© metal. N√£o h√° mudan√ßa de ideia no √ļltimo momento. N√£o h√° uma tecnologia que surgiu no √ļltimo momento e tornou tudo obsoleto. ¬†Um pouco mais semelhante seria um carro costumizado ou um avi√£o costumizado como Air Force One. Mais pr√≥ximo ainda seria um vestido de noiva. A tecnologia √© muito simples e conhecida, mas os requisitos s√£o muito vol√°teis. √Č por isso que existem costureiros de grife cobrando caro por essas coisas. Do outro lado, temos as vacinas, aqui os requisitos s√£o simples – evitar a doen√ßa , mas a tecnologia tem que ser criada. E algumas , como a da AIDS n√£o tiveram sucesso at√© hoje. ¬†A vacina √© um exemplo muito mais pr√≥ximo da complexidade de fazer um software com tecnologias novas (muitos projetos de vacinas falham, como falham os projetos de software). E talvez por isso as equipes tendam a usar tecnologias velhas. D√°-lhes uma margem maior de seguran√ßa emocional (se bem que uma plataforma de aplica√ß√£o velha √© um empecilho em si mesmo). ¬†Armas de energia com o phaser do Star Trek ainda s√£o uma ilus√£o, mas as armas ¬†taser est√£o bem perto, e cada vez mais perto de uma arma de energia. Aqui, o requisto continua simples – desabilitar o advers√°rio, mas a tecnologia √© simplesmente desconhecida. Um exemplo de algo bem complexo de criar seria uma verdadeira ¬†TARDIS , pois n√£o apenas ela √© um ser vivo que viaja no tempo e no espa√ßo, como √© maior por dentro do que por fora. Um desafio ao racioc√≠nio humano mais fundamental, o que dizer ao racioc√≠nio de engenharia.

Ao fazer software é raro que tenhamos requisitos bem conhecidos, e normalmente as empresas se encarregam de estragar a outra variável não tendo uma tecnologia padrão para desenvolver o software, o que significa que a cada projeto temos que começar de novo aprendendo novas tecnologias e refazendo funcionalidades que já tinhamos antes. Isto torna a produção de software inerentemente complexa. Não somos nós que a fazemos complexa, ela é complexa por natureza. O que podemos fazer é torná-la mais ou menos complexa, mas nunca apenas complicada ou  simples. Normalmente a tornamos mais complexa do que natural.

Aceitar este princ√≠pio b√°sico – “princ√≠pio zero”, poder√≠amos¬†cham√°-lo – √© fundamental para conseguir fazer software. Isto era verdade a 50 anos atr√°s, e com a velocidade com a tecnologia evolui,¬† √© muito mais verdade hoje. N√£o √© por acaso que nasceram coisas como o Java e o .NET para quebrar um pouco desse escalar de tecnologia que constantemente nos exigia mudar de ferramentas para fazer software. As plataformas virtuais nos trouxeram uma √Ęncora que nos ajuda a diminuir a complexidade. Mas a √Ęncora¬†n√£o durar√° por muito tempo e novas √Ęncoras precisar√£o ser desenvolvidas.

Entendendo que fazer software √© algo complexo, as pessoas esperam que a forma de gerenciar a produ√ß√£o do software tenha que ser igualmente complexa. E este √© outro paradigma¬†dif√≠cil¬†de quebrar: ¬†o complexo pode ser gerenciado com o simples. ¬†O truque √© mantermos os olhos nos objetivos. E s√£o estes que t√™m que estar claros desde o dia um, e refinados todos os dias. Como j√° disse Dwight D. Eisenhower¬†“O plano n√£o √© nada, planejar √© tudo”. Ou seja, a complexidade √© tratada facilmente se o plano n√£o for fixo e evoluir conforme as circunst√Ęncias. Mas veja, o plano muda e √© descart√°vel, mas n√£o os¬†objetivos¬†¬†(e se voc√™ tem algum sentido de √©tica, nem todos os caminhos s√£o aceit√°veis). ¬†Algumas pessoas entendem esta frase assim: “n√£o fa√ßa planos”. √Č errado. A mensagem √© “Fa√ßa planos, e continue fazendo planos. N√£o pare de fazer¬† planos at√© chegar no objetivo”. A cada plano temos um mapa do caminho para os pr√≥ximos tempos¬† ( horas, dias, semanas, meses, anos… n√£o interessa), quando replanejarmos teremos um plano que vai um pouco mais √† frente e assim continuamente. A mal intrepreta√ß√£o deste simples conceito leva a aberra√ß√Ķes como a recusa de criar uma plataforma de aplica√ß√£o coerente e coesa ou simplesmente achar que √© poss√≠vel levantar requisitos “on-the-fly” na medida que o projeto progride.

A complexidade do software demanda o processo criativo contínuo, e isso exige a atuação de pessoas em todos os pontos desse processo. Todo o resto são ferramentas.
Ser√° que o processo unificado (UP) ou qualquer outro processo criado antes de 1990 se baseia nestes princ√≠pios? Quero crer que n√£o. Todos os processos cl√°ssicos se baseiam num mecanismo Stage-Gate como o usado para construir carros e avi√Ķes (!). Este tipo de processo simplesmente n√£o funciona quando a principal energia √© a criatividade,¬† e √© por isso que muitos de projetos de software falham.¬† Em qualquer outro ramo de atividade, tantos projetos falharem √©¬†inadmiss√≠vel. Em software, fazemos de conta que n√£o √© verdade.

O que n√£o √© admiss√≠vel √© que seja¬†poss√≠vel¬†viver construindo software sem ter um processo-base para tal. ¬†Pr√°ticas de laborat√≥rio at√© temos algumas (vide pr√°ticas de XP ) e temos alguns candidatos a processos de gerenciamento realista de software como Scrum. Mas ainda aguardamos o santo graal do processo de software. ¬†O Processo Unificado n√£o √© bom o¬†suficiente porque ele √© muito semelhante a um processo Stage-Gate ¬†e √© corrompido muito¬†facilmente se transformado num processo que tradiconalmente √© usado em empresas produtoras de software. Um processo criado “in-house”,¬†h√≠brido¬†e muito parecido com um Frankeistein , um monstro fabricado de partes de outr√©m.

A promessa de um processo padrão moderno, confiável, honesto, que tome em consideração a complexidade, os requisitos, as tecnologias, e as pessoas ainda está por vir.  A minha aposta é que será algo muito semelhante a uma fusão de Scrum com XP e diretivas do manifesto de software craftsmaship que apela a um certo padrão de qualidade e orgulho no trabalho que fazemos Рque por exemplos os alfaiates têm Рque nós,  produtores de software, ainda não temos.

Software é simplesmente complexo, e é por isso que gostamos de o fazer. Aceitemos de uma vez por todas a sua complexidade natural e façamos-o com o respeito que merece.

Um comentário para “Simplesmente complexo”

  1. Simplesmente inspirador, nada mais correto e justo considerar nossa missão da forma como é descrita.

Comente

Artigos