Desenvolvimento Orientado a Modinha (DOM)

Você já trabalhou  com equipes que usam aquela metodologia de desenvolvimento infalível, o Desenvolvimento Orientado a Modinha? Você mesmo já usou (e/ou está usando) a mais nova tecnologia de software que aquela grande empresa lançou mês passado? Precisamos conversar sobre Hype Driven Development.

Equipes de desenvolvimento de software muitas vezes tomam decisões sobre arquitetura de software ou pilhas tecnológica com base em opiniões imprecisas, mídias sociais e, em geral, sobre o que é considerado “quente” (hype), em vez de sólida pesquisa e qualquer consideração séria do impacto esperado em seus projetos. Essa tendência pode ser chamada de Desenvolvimento Orientado a Modinha ou DOM —  originalmente, Hype Driven Development. Obviamente, existe uma abordagem mais profissional, chamada por alguns de Engenharia de Software Sólido (Solid Software Engineering). Saiba mais sobre como ele funciona e descubra o que você pode fazer em vez disso.

Nova tecnologia, nova esperança

Qual seu hype favorito?  :-) Tuitar isso

Soa familiar? Uma equipe escolhendo tecnologia mais recente, mais “quente” para aplicar no projeto e alguém lê uma postagem em um blog, vê que é tendência no Twitter e todos acabaram de voltar de uma conferência onde houve uma grande conversa sobre isso. Logo a equipe começa a usar esta nova tecnologia brilhante — ou paradigma de arquitetura de software –, mas em vez de ir mais rápido (como prometido) e construir um produto melhor,  começa a se deparar com sérios problemas.

A velocidade de desenvolvimento diminui, todos ficam desmotivados, têm problemas para entregar a próxima versão do projeto para a produção. Algumas equipes ainda mantêm a correção de bugs em vez de fornecer novos recursos. São necessários “apenas mais alguns dias” para resolver tudo…

Desenvolvimento Orientado a Modinha ou Hype Driven Development

O Desenvolvimento Orientado a Modinha (ou Hype Driven Development) vem em muitos sabores e toca seu projeto de muitas maneiras diferentes:

• Desenvolvimento Orientado a Reddit. Quando uma equipe ou indivíduo decide sobre a tecnologia/arquitetura/design com base no blogueiro popular que escreveu o que está quente no Reddit, Hacker News, blog do Twitter, Facebook, GitHub ou outras mídias sociais.
• Desenvolvimento Orientado a Conferência. Observe cuidadosamente o que acontece depois que pessoas (e programadores) retornam de uma conferência: elas ficam inspiradas. E isso é uma espada de dois gumes: começar a usar o mais novo paradigma/biblioteca/framework/arquitetura sem pesquisa suficiente pode ser uma estrada para o inferno.
• Desenvolvimento Orientado ao Cara que Fala Mais. As decisões mais influentes são as do que está falando o tempo todo sobre esse novo framework/biblioteca/tecnologia que ele não tem experiência, mas fala sobre isso o tempo todo e finalmente a equipe decide adotar a coisa.
• Desenvolvimento Orientado a Gem/lib/plugin. Um viés especialmente forte na comunidade Ruby On Rails, em que é possível ver um Gemfile por tanto tempo que a única coisa que leva mais tempo é para carregar o aplicativo. Vem da idéia de que cada problema em Rails deve ser resolvido através de um gem — sendo que, às vezes, apenas uma ou duas linhas de código dariam conta do recado ao invés de resolver o problema acrescentando mais problemas com libs, plugins, gems e/ou frameworks.
• Desenvolvimento Orientado a Stack Overflow. Certamente uma das mais comuns de acontecer, dá-se quando programadores copiam e colam soluções do Stack Overflow (ou encontradas na web, em geral) sem realmente entendê-las.

A raiz de todo o mal?

O problema com hypes é que eles facilmente levam a más decisões. Tanto a decisões arquitetônicas ruins, quanto a decisões tecnológicas sobre stacks costumam assombrar uma equipe meses ou mesmo anos mais tarde. No pior caso, elas podem levar a outra situação muito problemática em engenharia de software: A Grande Reescrita (The Big Rewrite).

A raiz de todo o mal parece estar nas mídias sociais, nas quais novas idéias se espalham muito mais rápido do que são testadas; muito mais rápido do que as pessoas são capazes de compreender os seus prós e contras.

A anatomia de um hype

A maioria dos hypes têm uma estrutura similar a esta:

Passo 1: Problema real e solução

Eles começam em alguma empresa com um problema. Uma equipe dentro de alguma empresa decide que a solução para o problema está além da pilha tecnológica atual, processo ou arquitetura. A empresa cria uma nova estrutura, biblioteca ou paradigma e logo o problema é resolvido.

Passo 2: Buzz & Keywords

A equipe está animada para mostrar seu trabalho para o resto do mundo e logo eles escrevem posts e fazem palestras e conferências. O problema muitas vezes não é trivial, então eles se orgulham de apresentar os resultados impressionantes de uma solução “da casa”. As pessoas ficam entusiasmadas com a nova tecnologia. O maior problema é que nem todos que ficam animados são capazes de compreender exatamente qual era o problema inicial e todos os detalhes da solução — afinal, tratava-se de um problema não-trivial com uma solução não-trivial.

Leva mais do que um tweet, bate-papo ou post no blog para explicar. Com ferramentas de comunicação como mídias sociais, artigos de blogs e conferências-relâmpago, ocorre muito ruído na comunicação e a mensagem fica “borrada” ao longo do caminho.

Passo 3: Obsessão

Toda força do hype leva desenvolvedores a lerem artigos e a participarem de conferências sobre a tecnologia. Logo as equipes de todo o mundo começam a usar a usá-la. Devido à mensagem “borrada”, algumas delas tomam decisões precipitadas de uso da tecnologia — mesmo que ela não resolva qualquer um de seus problemas reais. No entanto, a equipe tem expectativa de que esta nova tecnologia vai ajudar.

Passo 4: Desapontamento

Conforme os sprints passam, a tecnologia não melhora a vida da equipe tanto quanto as pessoas esperavam, mas traz muito trabalho extra. Há muita reescrita de código e aprendizagem extra para a equipe. As equipes diminuem a velocidade, a administração fica chateada. Todos se sentem enganados.

Passo 5: Realização

Finalmente, a equipe faz uma retrospecção e percebe quais são os prós e contras da nova tecnologia e para que finalidade ela seria mais relevante. Todos ficam mais sábios… Até o próximo hype aparecer.

Exemplos reais de hypes

É só pensarmos um pouquinho para lembrar de alguns exemplos reais do “Ciclo do Hype”, em ocasiões que trouxeram muitos infortúnios para muitas equipes de desenvolvimento pelo mundo.

React.js

1. Problema real e solução. SPAs, como o próprio Facebook, têm tantos eventos de mudança de estado que é difícil manter o controle do que está acontecendo e manter o estado do aplicativo consistente.
2. Buzz & Keywords. “Funcional”, “DOM Virtual”, “Componentes”.
3. Obsessão. “Facebook criou a estrutura front-end do futuro! Vamos escrever tudo em React de agora em diante!”
4. Desapontamento. Há muito trabalho, mas nenhum retorno rápido sobre o investimento.
5. Realização. React é ótimo para SPAs avançados com muitas notificações em tempo real, mas não necessariamente vale a pena para aplicativos mais simples.

“TDD está morto”

1. Problema real e solução. David Heinemeier Hansson (criador do framework Ruby on Rails) percebe que é difícil fazer TDD com Rails — já que ele não tem uma boa arquitetura, que comporta OOP — e faz uma escolha pragmática: não escrever mais testes antecipadamente; não trabalhar mais com TDD.
2. Buzz & Keywords. O hype começa com um post no blog de DHH e uma conferência. Termo-chave do hype: “TDD está morto”.
3. Obsessão. “Vamos pular os testes! Nosso Guru diz isso. Nós não escrevemos eles de qualquer maneira. Agora, pelo menos, não estamos fingindo. Finalmente somos honestos.”
4. Desapontamento. Há muito trabalho, mas nenhum retorno rápido sobre o investimento.
5. Realização. “TDD não está morto ou vivo. TDD está sujeito a tradeoffs, incluindo o risco de mudanças de API, habilidades dos participantes e design existente.” — Kent Beck.

Microservices

1. Problema real e solução. Grandes aplicações monolítica têm escalonamento difícil. Há um ponto em que é possível dividí-las em serviços. Será mais fácil de escalar em termos de req/sec e mais fácil de escalar entre várias equipes.
2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “Baixo Acoplamento”, “Monolítico”.
3. Obsessão. “Temos um ‘código de espaguete’ porque temos uma arquitetura monolítica! Precisamos reescrever tudo para microservices!”
4. Desapontamento. Agora é mais lento desenvolver o aplicativo. E difícil de implantar e se passa muito tempo rastreando bugs em vários sistemas.
5. Realização. Microservices exigem habilidadess “devops” na equipe. Antes de se chegar a graves questões de escalonamento, são um um investimento excessivo. Microservices são extraídos, não escritos.

NoSQL

1. Problema real e solução. Bancos de Dados SQL têm problemas com cargas elevadas e dados não estruturados. Equipes de todo o mundo começam a desenvolver uma nova geração de BDs.
2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “BigData”, “Alta Performance”.
3. Obsessão. “Nosso banco de dados é muito lento e não é grande o suficiente! Precisamos do NoSQL!”
4. Desapontamento. “Precisamos usar JOIN nas tabelas? Isso é problemático”. Operações SQL simples se tornam cada vez mais desafiadoras. O desenvolvimento fica lento e os principais problemas não são resolvidos.
5. Realização. NoSQL são ferramentas para resolver problemas muito específicos — tanto volumes extremamente elevados de dados, dados não estruturados ou cargas muito altas. SQL é realmente uma ótima ferramenta, capaz de lidar com alta carga e volumes de dados enormes se for bem usada.

Elixir e Phoenix (ou sua dobradinha favorita de linguagem/framework)

1. Problema real e solução. Frameworks web como o Ruby On Rails não lidam bem com aplicativos de alto desempenho, aplicativos distribuídos e websockets.
2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “Alta Performance”, “Distribuído”, “Tolerante a Falhas”.
3. Obsessão. “Nosso aplicativo é lento e nosso bate-papo não é escalável!”
4. Desapontamento. “Aprender programação funcional e abordagem distribuída não é tão fácil. Agora estamos muito lentos.”
5. Realização. Elixir e Phoenix formam um excelente framework, mas demanda um esforço significativo para aprender. Haverá retorno a um longo prazo se você precisa especificamente de um app de alto desempenho.

E a lista continua…

O espaço lotado da Engenharia da Computação apresenta muitas áreas em que hypes são comuns. No mundo do JavaScript, por exemplo, novos frameworks  são criados todos os dias. Node.js, Programação Reativa, Meteor.js, Front-end MVC, React.js. Na engenharia de software nascem novas arquiteturas: Domain Driven Development, Hexagon, DCI…

Qual é o seu hype favorito?  :-)

Boas práticas para evitar o DOM

Aprenda sobre uma tecnologia não somente de blogs, mas com a experiência. Tuitar isso

Então, se não podemos confiar no que a internet diz e opiniões de outras pessoas, como tomar decisões inteligentes em relação ao Desenvolvimento Orientado a Modinha? Eis algumas dicas e boas práticas.

Teste e pesquise antes de decidir

Aprenda sobre uma tecnologia não somente de blogs, mas com a experiência. A caráter de testes, invista 1 ou 2 dias para construir um protótipo de alguma funcionalidade na nova tecnologia antes de tomar uma decisão. Deixe a equipe analisar os prós e contras. É possível usar algumas tecnologias competitivas e permitir que diferentes partes da equipe construam protótipos com tecnologias diferentes.

Participar de hackathons é uma ótima maneira de construir a consciência de uma equipe através da análise de tradeoffs de diferentes tecnologias. Tome 1 ou 2 dias para toda a equipe testar todas as tecnologias que estão em ascensão. Isso permitirá que a equipe tome decisões inteligentes por si mesma, com base em sua própria experiência.

Quando arriscar?

A princípio, quando o retorno do investimento é enorme. A maioria das tecnologias são criadas para resolver um problema específico. Você tem esse problema? É um problema grande? Será que vai economizar muito tempo? Será que o uso da tecnologia paga o custo da curva de entrada e reescrita? E se inicialmente retardarmos o desenvolvimento pelo fator de dois? Ou quatro? Ainda vale a pena?

Algumas equipes são mais rápidas do que outras em entregar valor, chegando ao ponto de ficarem entediadas ao realizarem entregas de maneira mais fácil. Essas equipes podem introduzir novas tecnologias com mais freqüência — por outro lado, se a equipe tem problemas com entregas, este um forte indício para proceder com cautela.

Trabalhe com as pessoas certas

Ter uma formação técnica sólida é essencial: pessoas que conhecem diferentes paradigmas, compreendem a teoria da programação (por exemplo, algoritmos, concorrência etc) e têm boa cultura de engenharia tendem a ser menos suscetíveis a hypes.

Experiência também conta muito. Hypes impressionam mais desenvolvedores jovens. Com o passar dos anos, as pessoas que viram muitas tecnologias e estiveram em problemas muitas vezes tendem a ter uma visão mais equilibrada da tecnologia e sabem escolher melhor.

Conclusão sobre Desenvolvimento Orientado a Modinha

Desenvolvimento Orientado a Modinha (ou Hype Driven Development) não é novidade. Acontece de de um hype realmente se consolidar no mercado e se tornar “a nova melhor prática”, mas a quantidade de hypes é tão grande que, estatisticamente, poucos são os que alcançam o status de “paradigma” e se mantêm lá.

As dicas de testar e pesquisar, saber quando arriscar e trabalhar com as pessoas certas — com ênfase aos não tão jovens e/ou aventureiros — realmente surtem resultados. Seguí-las pode determinar o sucesso ou fracasso de seus negócios no mundo dos softwares.

O bom senso sempre foi um dos melhores aliados de todos nós. Parece que é hora de começar a dar mais atenção a este velho amigo.