Na última semana, ocorreu um evento peculiar sobre desenvolvimento de software, a Better Software Conference, em português, Conferência por Software Melhor. O nome parece pretensioso, mas não é. Somente reconhece que o software poderia ser melhor, algo com o qual qualquer desenvolvedor seria obrigado a concordar, mas não se afirma conhecer solução perfeita para todos os problemas, como todos os gurus da área costumam fazer. O evento foi um desdobramento de uma iniciativa antiga, chamada Handmade Hero, iniciada pelo programador de jogos Casey Muratori numa tentativa de ensinar a essa geração de programadores como as coisas eram feitas antigamente, sem todo o ferramental e todas as convenções que conhecemos hoje.
Em sua palestra, Muratori fez uma longa e interessante exposição sobre a origem de um famoso paradigma de programação, a Programação Orientada a Objetos. A ideia é tão prevalente que praticamente é confundida com o ato de programar, e esse levantamento histórico é importante, ao menos do ponto de vista de engenharia, para se entender o que passava na cabeça de seus idealizadores e quais problemas estavam tentando resolver. A conclusão é típica: vários conceitos fundamentais se perderam no tempo, elementos importantes foram deixados de lado em favor de coisas secundárias, um telefone sem fio resultando num desenvolvimento caótico. Esse resgate é fundamental, não porque esse modo de se organizar software seja ruim, mas porque certamente não é o que queremos em todas as situações e, para usá-lo de maneira eficiente, devemos entender que problemas estavam sendo resolvidos dessa forma.
Ainda que tenha sido a palestra mais longa do evento (era evidente a influência de Muratori tanto na audiência como nos demais palestrantes), talvez não tenha sido a mais interessante, ou melhor intrigante. Damos esse posto à palestra de Eskil Steenberg, Finish your software, ou Termine seu software. Para um leigo, a proposta pode parecer sem sentido. Talvez para um hobista que não consegue tempo para terminar seus projetos? Não, Steenberg faz a colocação de modo geral e parte de um princípio simples, comparando com outras áreas da engenharia. Uma ponte, um prédio, um automóvel, ou até mesmo um computador são coisas que, num determinado momento, ficam prontas sendo enviadas a outras pessoas que podem usá-las como bem entenderem. O software, por outro lado, é algo em constante evolução (muitas vezes eterna evolução).
É claro, pontes, automóveis e outros bens materiais sofrem deterioração e, por esse motivo ou por falhas de projeto, acabam precisando de manutenção, mas isso não é mais parte do desenvolvimento do produto. No mais, como argumenta Steenberg, essas coisas estão sujeitas às intempéries do mundo real enquanto o software é feito de bits, são instruções para um computador. Numa outra metáfora, podemos comparar o conteúdo de um livro com sua versão impressa: o que deteriora é o papel, não a ideia (mais formalmente, a propriedade intelectual) que estava impressa naquele papel.
Mas acontece que o software se deteriora. Um programa feito para macOS, o sistema operacional da Apple, em 2015, somente 10 anos atrás, já não é executável em sua última versão, exceto se o desenvolvedor atualize seu software. O mesmo vale para a maioria dos dispositivos móveis. A tecnologia “evolui” sem nenhum compromisso com a compatibilidade com aquilo que executa sobre ela, como se um urbanista pudesse reorganizar cidades livremente sem considerar o que já estava construído em suas ruas. É uma peculiaridade de uma indústria extremamente monopolizada que consegue, por exemplo, impor mudanças até mesmo de hardware como alterações arbitrárias de portas de conexão. Imaginem se algum fabricante de carro resolvesse mudar o formato do bico de combustível…
Nem todas as plataformas são como o macOS. No caso do kernel do Linux, a retrocompatibilidade sempre foi um valor importante, pois retem a base de usuários e estabelece um laço de confiança de que é possível desenvolver naquela plataforma e que seus projetos continuarão nela a funcionar no futuro. Ainda assim, esses são sistemas operacionais e muitos programas dependem de muitos outros programas além desses, bibliotecas de código, e essas podem não ter um compromisso tão firme sobre suas interfaces.
Steenberg afirma em sua palestra que todo software deveria ser possível de ser feito por uma única pessoa. Ele não afirma isso do ponto de vista “anarco-capitalista”, comum a muitos programadores. Em seu raciocínio, ele aponta que é sempre possível quebrar uma determinada funcionalidade desejada em múltiplos projetos de software, e essas subdivisões devem poder ser realizadas por uma pessoa. Se todos respeitarem as interfaces de seus programas (como no exemplo do Linux), programas que dependem uns dos outros continuarão a funcionar em harmonia. Seu argumento propõe uma intensa colaboração entre seres humanos. Assim como usamos um computador que outras pessoas construíram para escrever este texto, por exemplo, outras pessoas podem usar nosso software para construir outras aplicações que sirvam os seus interesses ou os de terceiros.
Essa seria a solução racional, do ponto de vista de engenharia. Ainda haveria erros e algumas interfaces precisariam evoluir, mas não há porque quebrar algo que já estava funcionando. O motivo para tal é sempre uma contribuição negativa do capitalismo e suas relações de posse: algum monopólio quer que você deixe de usar o que lhe servia para adotar a nova solução e, naturalmente, pagar por ela. A versão degenerada disso é a infinidade de serviços por assinatura que temos hoje em dia. O software não apenas não termina, como nunca termina.
O que falta para uma plataforma como o Uber ser considerada pronta? Ou o Google? O iFood? Por que designers insistem em mudar a cor e o lugar de botões em programas que, ainda que não fossem os melhores possíveis, atendiam as necessidades de seus usuários? Por que quebrar contratos estabelecidos com programadores que buscavam de alguma maneira interagir com essas plataformas? Há sempre o argumento da segurança, mas essa é uma falácia porque, para toda falha de segurança, há uma forma de contorná-la. Talvez não seja a mais eficiente, mas o que é mais custoso: reintegrar todos os programas que interagiam com a sua interface ou deixar seu código mais “feio” e resolver o problema com uma gambiarra? Argumentaríamos que o dono do problema é aquele que o causou, então, se alguém tem que arcar com o ônus de um problema de segurança, esse alguém é aquele que fez o software inseguro em primeiro lugar.
O que mais nos surpreende é que esse tipo de acordo é comum a quase todos os outros tipos de engenharia. Esse estabelecimento de interfaces entre diferentes áreas de trabalho é o que permite a divisão do trabalho e o ganho de produtividade em primeiro lugar. A Engenharia de Software, por outro lado, promove a “disrupção” como um valor essencial. Steenberg destaca como essa disciplina se preocupa com a manutenibilidade do software, dando a entender que ele será mais mantido que usado. O valor essencial de qualquer produto é sua usabilidade.
A Better Software Conference é um respiro num mar de jargões e ideias recicladas que permeia a nossa área de atuação. A Engenharia de Software precisa ser uma disciplina que se pareça mais com uma engenharia e menos com uma filosofia que justifica sua própria existência. Por que tanta empolgação com ferramentas de inteligência artificial e a possibilidade de se produzir mais software sem questionar se esse software será útil? Precisamos de mais software ou de software melhor? Vejamos, por exemplo, quantos aplicativos para organizar tarefas existem… Ainda não conseguiram resolver esse problema?
Para uma indústria que adora bajular a si mesma, em que executivos se apresentam como grandes gênios da humanidade, resta a pergunta: por que estamos sempre reescrevendo os mesmos programas? O que o Microsoft Word de hoje faz melhor que o de 1995? Ele é mais rápido e responsivo? Não, e ainda roda num dispositivo muitas vezes melhor que qualquer coisa de 20 anos atrás. Ainda assim, o Word certamente já foi reescrito mais de uma vez num esforço de centenas de profissionais muito bem pagos. Por que estamos gastando centenas de milhões, senão bilhões, na refação de soluções que poderiam simplesmente continuar funcionando como antes? Para empresas e profissionais que se orgulham de sua eficiência, uma autoavaliação demonstra seu exato oposto.
