Building Minds - o Blog da OnCast

Na engenharia civil, você faz um projeto de um edifício, planeja a execução e a executa. E funciona. Não me admira que muitos façam paralelos dessa fórmula para a engenharia de software, se funciona para civil, deve funcionar para para outros tipos de projeto.

Bem, com o passar dos anos, a medida que a idéia de projeto foi sendo inserida na engenharia de software foi se percebendo que não funciona bem assim. Os requisitos mudam o tempo todo, o cliente não tem certeza do que precisa, a equipe tem muitas dúvidas, há muito impedimento, pouco pode ser antecipado. O que é que há de errado?

Foram usados os mesmo conceitos da engenharia civil: planejar, alocar recursos e colaboradores para o projeto, executar. Tudo certo, como devia ser, e como sempre funcionou. Mas na engenharia de software não funcionou! Por que?

Muitos clamaram que construir um edifício é diferente de construir software. Que não se pode mudar uma casa dois metros para direita depois que os alicerces já tiverem sido construídos. Que a engenharia civil tem muito tempo de existência e por isto está madura e que por isso funcionam bem projetos na civil e não no software.

É tudo mentira. Engenharia civil e engenharia de software são sim muito parecidos! Depois de ter passado por inúmeros projetos eu percebi que sim engenharia civil e engenharia de software são idênticos em natureza.

É inegável que planejar tudo a priori e executar não funciona em software. O problema é que ninguém percebe que isso também não funciona em engenharia civil. De volta ao primeiro parágrafo: “Na engenharia civil, você faz um projeto de um edifício, planeja a execução e executa”…

“você faz um projeto de um edifício”… Isso vem antes de planejar a execução. Quando se projeta um edifício como o Gate Capital em Abu Dhabi, ou a ponte da baía de Hangzhou na China, ninguém começa a fazer nenhum tipo de alicerce sem ter a ponte bem projetada antes, nem mesmo a execução da obra é planejada. A falha que se há na metáfora da construção civil para software é que criar software é executar, quando na verdade é projetar.

Quando essas duas obras incríveis da engenharia civil foram projetadas (não construídas) todo tipo de desafio apareceu. Os requisitos mudaram o tempo todo, o cliente não sabia o que queria exatamente, a equipe tinha muitas dúvidas, haviam muitos impedimentos, pouco pôde ser antecipado. Esses problemas só terminaram quando o projeto arquitetônico acabou, exatamente como em software. A erro da metáfora da construção civil não está em hipotéticas diferenças entre civil e software, o erro é que software é 99,999% projeto e apenas 0,001% planejar a execução e executar.

Na fase de projeto você sempre pode mudar um prédio 2 metros para a direita, você pode até ver como ele ficaria de cabeça pra baixo no Cad, ver como iria desmoronar e tudo mais. Fazer simulações de resistência das colunas, testar o comportamento de um modelo contra correntes de vento. Idêntico a software.

Em software a execução é feita por scripts automatizados, eles pegam o projeto (que é o código fonte) e transformam na obra final (o executável para produção). Na engenharia civil o projeto é passado para o planejamento de execução, em software este projeto não são documentos como diz os métodos mais tradicionais, mas sim o próprio código fonte.

O erro foi sempre acreditar que os códigos fonte são os tijolos do edifício, quando na verdade eles são as especificações do edifício. A parte com maior apelo público da engenharia civil é a execução da obra, ver aquela estrutura imensa se levantar do chão ou do mar é sempre muito legal. Mas essa parte em software é trivial, um mecanismo automático faz por nós.

A parte criativa do processo de engenharia civil é que é interessante para a engenharia de software. Os arquitetos de edifícios têm os mesmos problemas dos analistas e arquitetos de software: entender o que o cliente quer, fazer um esboço, apresentar, refazer o esboço com os novos insights, apresentar, criar um modelo (código) e apresentar de novo, refinar e refinar até que as expectativas estejam alinhadas. Os engenheiros civis tem os mesmos problemas dos engenheiros de software e testers: verificar que o modelo está ok, testar o modelo contra as intempéries do ambiente (vento, solo, materiais, performance em produção, integração com outros sistemas), refinar, refatorar o modelo, entrar em consenso e negociar alternativas. É tudo idêntico. E depois que você termina o seu projeto, você roda o build para por em produção.

Idêntico.

Rodrigo Machado Outros

Defino Débito Técnico como a distância entre o estado de um artefato técnico e como ele o seria em seu estado da arte. No ramo de desenvolvimento de software, é a medida de quanto uma deficiência técnica compromete o futuro do projeto e pode ser utilizado para antecipar problemas como bugs, baixa produtivadade, dificuldades com manutenção e dificuldades com transferência de tecnologia. Sua unidade é o spag (Sg), ou spaghetti :).

O termo foi cunhado em 1992 por Ward Cunningham, mas até hoje não há consenso de seu significado. Steve McConnell divide Débito Técnico em duas categorias: Intencional e Não Intencional (leia seu artigo). Uncle Bob em seu artigo “A Mess is not a Technical Debt” fala que um débito técnico não intencional (negligente) não deve ser considerado débito técnico. Martin Fowler subdivide débito técnico de duas maneiras: Prudente/Imprudente e Intencional/Inconsciente, gerando os quadrantes de débito técnico.

Minha classificação é algo como a de Steve. É muito útil determinar a existência de um Débito Técnico apenas avaliando o software em si, sem considerar as condições em que foi inserido. A separação entre intencional e não intencional não pode ser determinada apenas analisando o artefato. Um código mediano não é inapropriado se houve estratégia e todos estão conscientes das consequências da sua inserção.

Logo, a todo código ruim ou mediano dou o nome de Débito Técnico, a todo código que compromete o produto ou o futuro do projeto. É uma métrica direta da qualidade do software. Utilizo a subdivisão Intencional/Inconsciente para identificar se houve/não houve justificativas estratégicas para tal débito. As classificações Prudente/Imprudente dadas por Martin, credito mais à equipe, e não ao débito técnico em si.

Vamos descorrer um pouco mais sobre a distinção entre Débito Técnico Intencional e Débito Técnico Inconsciente.

Débito Técnico Intencional

Fazer o refactoring para abrigar a nova funcionalidade nos custará 5 dias, utilizar a arquitetura atual, mesmo que entortando alguns conceitos, nos custará 1 dia. Nossa entrega é no meio desta semana e a multa por atraso é indecente.

Qualquer gestor responsável diria:

1 dia! Faremos simplista agora! Agendamos um refactoring na próxima release, mesmo que nos custe 10 dias depois.

Existem momentos na vida de um projeto que atingir os deadlines é mais importante que a qualidade. O mundo está cheio de desafios: concorrência acirrada, time-to-market, pressões externas e internas… Não observar estes desafios é a pior das negligências de um projeto. De nada adianta um projeto que não atinge seus objetivos. Conhecer os prós e contras de suas estratégias é primordial para fazer a escolha correta.

Em uma boa equipe Scrum, o Product Owner tomaria esta decisão, principalmente porque conhece as necessidades do mercado. À equipe técnica (team) cabe o papel de levantar alternativas e alertar o Product Owner sobre os prós e contras de cada uma. O balanço entre qualidade e metas é o resultado esperado, bem como um agendamento de refactorings para amortizar o eventual débito técnico resultante.

Débito Técnico Inconsciente

Este débito técnico pode ser incorrido por algumas razões:

• Uma equipe técnica iniciante falha ao enxergar uma solução que não comprometa o futuro do projeto.
• O Product Owner é negligente ao considerar os riscos de suas ações, não considera os argumentos da equipe técnica e falha ao avaliar as necessidades de médio e longo prazo de seu projeto.
• O imponderável, algo que não pode ser antecipado nem por uma equipe sênior. Isto é comum a trabalhos de pesquisa e desenvolvimento de cunho científico.

De maneira geral, acredito que nem todo Débito Técnico não intencional seja negligente. Como visto acima, existem casos em que a complexidade do trabalho irá impor que débito técnico seja naturalmente inserido e permaneça desconhecido por algum tempo. Isto não configura negligência. Entretanto, ignorar o fato de que débitos técnicos serão inseridos é negligência. Cabe à equipe toda monitorá-los e corrigi-los a medida que sejam identificados.

Rodrigo Machado Metáforas, Riscos

Uma experiência interessante: Pegue uma pulga, a coloque em um pote e o tampe. O que você vai observar é que durante um tempo esta pulga ficará pulando e batendo contra a tampa na esperança de fugir. Passado algum tempo a pulga se condicionará a não pular tão alto já que pular alto não está se provando eficiente (a menos que o objetivo seja ter uma dor de cabeça).

O que acabou de acontecer com a pulga é o estabelecimento de um paradigma, um conjunto de regras que levam a uma conclusão, no caso “Pular alto não me levará a lugar algum”.

Abra a tampa e o que acontece? Ao contrário do esperado a pulga não vai fugir. O condicionamento impõe à pulga que ela não pule alto, o paradigma em que ela vive diz que pular alto não é uma boa prática.

Leia mais…

Rodrigo Machado Metáforas

Durante décadas, se não séculos, os administradores e gestores em geral sempre tiveram uma certeza: Para ter resultados você tem que motivar sua equipe, bonificando-os quando alcançam os resultados.

Parece bastante coerente este pensamento, e realmente é. Não reconhecer o comprometimento de sua equipe e os grandes resultados por eles alcançados não é só pouco humano como também uma grande falha de um líder. A recompensa é algo importante.

Agora vem o porém: lembre-se, recompensa não é pressão! Esse é o ponto em que o mercado hoje falha em perceber, e falha feio. Pressão em ambientes inovadores pode destruir toda a possibilidade de criativadade. Se você considera sua equipe inteligente e se o trabalho de sua equipe exige um mínimo de esforço intelectual, pressão (ou motivação que gere pressão) vai invariavelmente levar sua equipe a um desempenho menor. Você vai ficar frustado.

O vídeo abaixo mostra exatamente este fato, com número e exemplos. Ele explica a diferença entre motivação interna e motivação externa. Mostra a diferença de uma equipe comprometida com um problema que precisa de solução, e não comprometida com alcançar um bônus ou evitar de ser punido. Vale a pena ver.

Esse vídeo foi enviado pelo Jaime Schettini para nossa lista interna de discussão. Obrigado Jaime pelo vídeo!

Rodrigo Machado Auto-gestão

Comunicação e código? Por que o primeiro post neste blog falaria sobre algo tão distante de código como comunicação? E comunicação aqui não é nenhum protocolo utilizados em dois sistemas ou duas camadas, é comunicação entre pessoas mesmo.

O problema está justamente aí, comunicação e código são distantes nos paradigmas atuais de engenharia de software, principalmente nos mais tradicionais. Imagine um processo onde uma pessoa tem uma visão sobre um sistema informatizado, ele escreve esta visão, outra pessoa a lê, analisa e escreve outro documento detalhando o que o sistema deve fazer para atingir esta visão. Uma terceira pega este segundo documento, lê e implementa. Que tipos de problemas temos neste modelo de comunicação? Leia mais…

Rodrigo Machado Comunicação