Desenvolvimento

16 out, 2013

Manter software é um saco – e o que podemos fazer em relação a isso

1057 visualizações
Publicidade

Se você perguntar a maioria dos desenvolvedores, eles irão te dizer que trabalhar na manutenção de código é um saco. Entender e corrigir o código bagunçado de alguém é difícil, tedioso e frustrante – porque você sabe que poderia fazer um trabalho melhor se te dessem a chance de fazer tudo do zero direito.

Eu gosto de manter o código que escrevi. É minha responsabilidade pessoal para com os usuários. Por outro lado, manter código que não escrevi – e conviver com as consequências das decisões das quais eu não tive participação – é muito doloroso para mim. Jeff Atwood, Programming Horror

Muitos desenvolvedores de software enxergam a manutenção de código como uma sentença de prisão – ou pelo menos uma condicional. Eles foram para a escola para se tornarem engenheiros de software e acabam trabalhando como zeladores. Para desenvolvedores “de verdade”, manutenção é algo tedioso e massacrante.

Eu já mantive software no passado e, honestamente, é a maior merda com a qual eu já tive que lidar. Comentário de hotdog, no artigo A Nobre Arte de Manutenção de Software, do blog de Jeff Atwood, em outubro de 2008.

Manutenção é trabalho duro

Robert Glass, em seu ensaio Manutenção de Software é Solução, não um Problema, explica por que manter um software é tão difícil e impopular. Manutenção é algo:

  • Intelectualmente complexo – exige inovação ao mesmo tempo em que impõem severas restrições a quem inova. Encarregados pela manutenção precisam trabalhar dentro do design, além de questões regulatórias e governamentais, precisam tomar cuidado para manter a compatibilidade com outros sistemas e não podem arcar com erros que possam ter impacto nos clientes que já estão usando o sistema (razão pela qual mais da metade do trabalho de manutenção são testes).
  • Tecnicamente difícil – o mantenedor precisa ser capaz de trabalhar com o conceito, o design e com o código, tudo ao mesmo tempo; e ainda tem que entender tudo isso rápido.
  • Injusto – o mantenedor nunca consegue tudo de que precisaria, como boa documentação, boas ferramentas ou o tempo necessário para terminar o trabalho.
  • Só a parte ruim – o mantenedor lida apenas com usuários que possuem problemas, em vez de ter relações amigáveis com patrocinadores executivos em projetos de perfil estratégico.
  • Trabalho sujo – o mantenedor precisa fazer o trabalho sujo de escrever código e debugar, em vez de projetar a parte criativa da arquitetura, preocupando-se em criar e fazer o deploy do código, certificando-se de que ele está funcionando corretamente.
  • Vivendo no passado – mantenedores estão sempre vivendo com as opções e erros do design e da tecnologia de outras pessoas, em vez de resolver novos problemas e aprender novas ferramentas (o que significa que não há chances de embelezar seus currículos).
  • Conservadores – o mote dos mantenedores é “se não está quebrado, não corrija”, portanto ele precisam aguentar atalhos, “gambiarras” e concessões, e fazer a menor quantidade de trabalho possível para que a tarefa seja feita.

Mas, mesmo que isso signifique trabalho duro, pessoas fazendo trabalho de manutenção são subapreciadas – e normalmente sub-pagas também. As posições de “arquiteto de software” mais visadas com os maiores salários vão para as estrelas que trabalham em projetos estratégicos de desenvolvimento. Portanto, por que você – ou qualquer outro – deveria se preocupar se o trabalho de manutenção é terceirizado para a Índia, a Romênia ou qualquer outro lugar?

Manutenção de software é algo muito importante para ser um saco

Mas a verdade é que a manutenção é importante demais para ser ignorada – ou terceirizada. Ela é importante demais para as organizações e para desenvolvedores de software. Manutenção – e não desenvolvimento novo – é onde a maior parte do dinheiro em software é gasto e, goste você disso ou não, é onde a maioria de nós passaremos a maior parte de nossas carreiras, estejamos nós trabalhando em sistemas corporativos, construindo comunidades online, trabalhando em um fornecedor de cloud, uma microempresa de desenvolvimento, escrevendo aplicativos móveis ou software embarcado.

Atualmente, nos EUA, 60% dos profissionais de software (1,5 milhão de uma população estimada de 2,5 milhões) estão trabalhando na manutenção de sistemas de software (Caper Jones, Software Engineering Best Practices, 2010) e o número de pessoas trabalhando com a manutenção de software no mundo todo continuará a subir, porque continuamos a escrever novos softwares, e esses softwares precisam de suporte e manutenção. Podemos prever um futuro no qual quase todos nós passaremos a maior parte do tempo na manutenção, em vez de na criação de código novo.

Não é a manutenção que é um saco, e sim como a gerenciamos

Tentativas de gerenciar a manutenção usando modelos de governança formal baseados no ITIL service management ou em padrões estruturados de ciclo de vida de software como IEE-STD-1219 (ISO/IEC 14764) ou de aplicar o modelo de maturidade CMMi para a manutenção de software são infelizmente iniciativas muito caras, burocráticas e nada práticas.

Na maioria das organizações, a manutenção é feita de forma reacional, como parte de uma necessidade incontornável do suporte operacional de um negócio comum. A coisa com que os gerentes mais se preocupam é minimizar os custos e o desgaste. Qual é a menor quantidade de trabalho que precisamos fazer para evitar que os usuários reclamem, e como podemos fazer isso da forma mais rápida e barata? Se não podemos evitar isso, podemos terceirizar, talvez economizar algum dinheiro e fazer disso o problema de alguma outra pessoa, para que possamos focar em coisas “mais importantes”?

Esse pensamento de curto prazo continua ano após ano, até que o investimento que a empresa fez para criar o sistema, e as pessoas que o construíram já se exauriram. As pessoas inteligentes que costumavam se preocupar com fazer o trabalho direito já se foram há anos. A tecnologia já avançou a um ponto em que você tem mais um “sistema legado” que precisará ser substituído. Apenas um punhado de pessoas entendem o código e a tecnologia, e cada mudança leva mais tempo e custa mais do que vale. Os riscos técnicos e de negócios continuam a se acumular. Seus clientes estão cansados de lidar com bugs e de esperar pelas coisas que eles precisam. Em algum momento, não há outra opção a não ser jogar tudo fora e começar de novo. Que triste desperdício de tempo e dinheiro!

Temos que corrigir o mal-entendido de que a manutenção de software é um dreno na corporação, que ela suga a inovação: que a inovação só pode acontecer nas “verdes campinas” do desenvolvimento de projetos e que o dinheiro gasto em software que já foi escrito é um desperdício de capital. Que não é importante prestar atenção no que o seu negócio está fazendo hoje e que não é possível construir daí para o futuro.

Negócios voltados para software online como Facebook, Twitter e Netflix continuam a crescer e a inovar a partir daquilo que já fizeram, ao investir em seu pessoal e na base de código que eles já escreveram. Muito do trabalho que as pessoas estão fazendo nessas companhias hoje é manutenção: acrescentando outra “feature” ao código que já é usado, corrigindo bugs, tornando o sistema mais seguro, escalando para suportar aumento de carga, analisando dados de feedback, integrando com novos parceiro, talvez reescrevendo um app móvel para ser mais rápido e fácil de usar.

Esse é o mesmo tipo de trabalho de manutenção que outras pessoas estão fazendo em outras empresas e, no fundo, a tecnologia não é tão mais excitante assim. A diferença é como o trabalho deles é feito, como é gerenciado e como as pessoas enxergam seus empregos. Para eles, não é “manutenção” – é engenharia. Desenvolvedores são valorizados, respeitados e ganham confiança tanto quando eles estão fazendo coisas novas, quanto quando estão mantendo o que já existe. Eles são responsáveis pela oportunidade de resolver problemas interessantes, de experimentar e tentar novas ideias com clientes e de ver se essas ideias fazem alguma diferença. Eles trabalham em pequenos times, seguindo métodos de desenvolvimento de integração contínua, entrega contínua e deployment contínuo, e outras ideias e ferramentas criadas internamente pelo time de Devops para que as coisas sejam feitas rápido e eficientemente, com o mínimo de burocracia e outras bobagens do tipo.

Essas organizações provam como o desenvolvimento de software e sua manutenção devem ser administrados: contrate as melhores pessoas que você encontrar, conceda a elas a ação e a oportunidade de trabalhar com os clientes e de fazer uma diferença significativa, forneça feedback constante para que elas continuem aprendendo e criando produtos melhores; dê a elas as ferramentas necessárias e encoraje-as a continuar evoluindo o software e a forma como ele é criado, e mantenha-as responsáveis pelo sucesso do sistema (e da empresa).

Isso funciona. O que as outras empresas estão fazendo não. Não é a manutenção que é um saco, é a forma como a encaramos e a gerenciamos que é um saco. Mas isso é algo que podemos corrigir.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/07/maintaining-software-sucks-and-what-we.html