Mudança de paradigma no desenvolvimento de software


O assunto que é o principal conteúdo deste post à primeira vista “chove no molhado” de velhas promessas da área de computação sobre desenvolvimento com componentes e de metodologias para uma aproximação com as áreas de negócio que possa resolver o gap de comunicação acusado por ambos os lados. Tanto o negócio quanto os desenvolvedores de aplicações para o negócio reclamam e inculpam o outro lado pelo fracasso flagrante em termos de cumprir o que promete dentro do orçamento e no prazo. A “Torre Eiffel”, cuja obra atendeu aos três itens citados, não existe para a Engenharia de Software (um nome bastante inadequado). O termo “Engenharia” na expressão Engenharia de Software é inadequado por não capturar bem o que significa desenvolver software. Um empregado da Dupont ficou admirado ao saber que havia uma perda de cerca de 50% no processo de desenvolver software. É como que para cada carro fabricado um tivesse que ser jogado fora numa indústria de automóveis. Não entendia como se podia ganhar dinheiro com um trabalho desses. Sorrisos amarelos à parte, foi-lhe explicado que os clientes já tinham uma margem de tolerância para isto aceitando que era assim mesmo. O que se segue está intimamente ligado ao que se chama de “crise de software”.

Há 40 anos um empregado da IBM do Canadá, John Paul Morrison, com formação em Antropologia, já tinha começado a endereçar o problema. Seus trabalhos com sistemas de simulação (GPSS) o inspiraram a levar suas reflexões sobre as dificuldades para desenvolver software em direção a uma mudança de paradigma. Esta mudança de paradigma tem duas faces. Uma para os desenvolvedores e outra, mais importante segundo Morrison, para o lado do negócio. Um dos sonhos daqueles que trabalhavam com simulação é ver os seus sistema se metamorfosearem em sistemas de controle também. Afinal a análise necessária para construir um sistema de simulação é mais do que suficiente para as necessidades de uma aplicação de controle. Mas na época ainda não havia os recursos computacionais e clareza a respeito de como fazer isto.

Hoje a tendência à paralelização da execução do software é uma realidade com praticamente todos os computadores sendo fabricados com mais de uma CPU (cores), com as técnicas de clusterização e também com a distribuição de execução por uma rede de computadores, já amplamente explorada por sistemas de Big Data. No entanto programar os computadores para explorar estes novos recursos não é fácil e muitas vezes exige que os profissionais sejam super programadores, um recurso raro e caro. Uma abordagem para contornar o problema é tornar a programação de sistemas paralelos mais segura e fácil para os programadores médios, menos raros e mais baratos. A quantidade de programadores nestas condições cria um exército com tamanho suficiente para atender as demandas do negócio. Os super programadores ficam para os desenvolvimentos especiais dos frameworks para os programadores médios usarem, entre outras coisas menos frequentes. No limite os programadores médios acabam fazendo tarefas acessíveis a qualquer “mortal” normal. Para exemplificar vamos pensar no que é comumente chamado de Lego Programming. Vamos imaginar um pai que comprou um kit para robótica para crianças da Lego e o entregou como um brinquedo sofisticado para seu filho ou filha que esteja no nivel educacional adequado para seguir as instruções. Preocupado com a eficácia de sua iniciativa educacional (era um engenheiro que queria incutir o gosto pela engenharia nos filhos) resolve examinar mais de perto o “brinquedo”. Primeiro se surpreende com o grau de sofisticação e o potencial de aplicações. Pensa que aquilo é inacessível para a idade e a maturidade dos filhos. Investigando mais verifica surpreso que foi capturado pela simplicidade conceitual que faz a coisa funcionar e se pega “brincando” com aquilo. Percebe então não só o potencial educacional do Lego Programming para seus filhos mas como aquilo poderia ser generalizado para apoiar um indústria onde o processo de desenvolvimento de software esteja “embarcado” no negócio de uma forma horizontal, e não da forma verticalizada atual.

Foi isto aproximadamete o que aconteceu com Morrison. Só que a partir da sua experiência com sistemas de simulação. O que propôs na verdade é uma mudança de paradigma para o desenvolvimento de software que escapa do modelo Von Neumann. E implementou num banco, uma das instituições mais rigorosas em relação à confiabilidade e segurança de suas aplicações, além de serem instituições bastante reguladas. Morrison inventou algo cujo nome, Flow-Based Programming, é bem despretensioso mas cujas repercussões agora estão em ressurgimento, 40 anos após a sua invenção.

Flow-Based Programming tem uma simplicidade que, paradoxalmente, alavanca o seu poder. Os excertos abaixo são de uma série de artigos que estou escrevendo:

“Não se influencie pela palavra programming no título deste post. O conceito de Flow-Based Programming é bem abrangente e, na verdade, pode ser mapeado perfeitamente nas linguagens usuais de descrição de processos de forma bidirecional, eu diria. É uma linguagem com que o pessoal de negócio que entende de processos vai ter uma empatia imediata. John Paul Morrison propõe que os usuários vão projetar os sistemas com os blocos que os programadores vão construir conforme uma especificação dada a eles pelo pessoal de negócio. Cita claramente o sonho do Legoland Programming. (…) Em Flow-Based Programming o vocabulário também é limitado: Component, Connection, Packet (Information Packet – IP), e Port. (…) Um modelo simples assim é extremamente palatável aos usuários e encorajam o Lego Programming. O poder de uma tal abstração é tremendo e está gerando um frisson na Internet. (…)  Flow-Based Programming pode iniciar uma era de sucesso na direção da criação de um mercado de componentes de prateleira, na aproximação dos usuários ao desenvolvimento ativo de sistemas para atender os seus negócios e melhor aproveitamento da infra-estrutura de paralelismo que está despontando cada vez mais. A reutilização de componentes “técnicos”, desenvolvidos pelos profissionais de TI bem como daqueles desenvolvidos pelo negócio deve alavancar uma produtividade nunca vista antes. A reutilização de componentes de negócio sempre foi o calcanhar de Aquiles da indústria de software. Reutilizar widgets da interface com o usuário são bem previsíveis mas entender quais são os “átomos” do negócio (que são os componentes mais reutilizáveis, em princípio) e mesmo os componentes mais complexos, que somente os experts em cada área seriam capazes de detectar, é uma tarefa bem difícil. E se eles puderem “por a mão na massa” com uma linguagem visual e componentes disponíveis para serem conectados os sistemas poderiam evoluir de forma rápida e adaptativa às mudanças nos cenários dos negócios. Uma forma exploratória e menos rígida será gerada pelas novas facilidades no desenvolvimento de sistemas com base em protótipos que se tornam “adultos” (Morrison), que não são jogados fora violando a teoria dos protótipos feitos com “arame preso com chicletes”. Embora isto esteja mudando recentemente. O mundo do software é mais plástico do que o mundo físico ou do hardware. Um modelo de um carro feito de cerâmica ou plástico esculpido para ser testado no túnel de vento não pode depois circular nas ruas, mas um modelo em software é análogo ao que pode ser imaginado numa história de ficção científica em que o escritor faz a cerâmica se transmutar em metal.” (SmallFBP: a Smalltalk framework for Flow-Based Programming in Crab Log)

Uma das consequências de um modelo de componentes tem impacto direto no modelo de contratação de serviços de desenvolvimento de software. O uso de fábricas de software pode ser feito de forma mais eficaz e com menos dependência. Os métodos ágeis podem ser praticados pela empresa contratante utilizando componentes encomendados às fábricas. Às fábricas não seriam encomendados projetos de desenvolvimento mas apenas componentes com determinadas especificações. No limite alguns componentes com prazos críticos de entrega poderiam ser solicitados a fábricas concorrentes  com um bonus para quem entregasse primeiro. A empresa contratante não precisaria abandonar as sua práticas ágeis no desenvolvimento de sistemas em que pequenas equipes sejam suficientes (O desenvolvimento com equipes reduzidas é de eficácia tão flagrante para alguns projetos que o departamento de defesa do governo dos E.U.A. até estabeleceu uma lei que impões o seu uso na maioria dos casos, a menos de exceções bem específicas).

Um incômodo similar ao que ocorreu ao empregado da DuPont sobre a ineficiência do desenvolvimento de software nas bases atuais acontece comigo também. É facil perceber o paralelo com o que acontece no desenvolvimento de hardware e como o modelo é produtivo apesar da plasticidade do hardware não ser a mesma do software. No entanto imitar a rigidez do hardware, que força o sua reutilização, pode ser benéfico para o desenvolvimento de software. Os métodos de engenharia, que já provaram sua eficácia até agora, poderiam ser aplicados ao desenvolvimento de sistemas usando o novo paradigma. Morrison cita o paper On the Architectural Requirements of an Engineered System, de Nate P. Edwards, que não recebeu muita atenção no domínio de software devido ao seu background ser preponderantemente em hardware, onde ele estabelece as características fundamentais de um sistema modularizado e orientado à reutilização. O engenheiro de sistemas é estimulado a usar pacotes prontos e só construir algo novo se for estritamente necessário e vantajoso economicamente. O paper cita explicitamente a qualidade única em um sistema de desenvolvimento de software que é engineered:

The idea of applying engineering principles and practices to data processing systems and programming has been around since hardware engineers began to do programming in the 1950’s. With one exception, I am aware of no example of software system which exhibits most, if not all of the essentials of the engineering approach.This one exception is the Advanced Modular Programming System “AMPS” [N.A.: Precursor de Flow-Based Programming] invented by J. P. Morrison of IBM. It is specially notable in that it uses fully independent modules and configurable architecture principles.” (Architectural system requirements for data processing in On the Architectural Requirements of an Engineered System)

Voltando ao tema da adequação do termo Engenharia de Software muito já foi escrito a respeito. Martin Fowler em The New Methodology discute como os métodos ágeis são uma solução para o desenvolvimento de software. Há até uma distinção entre os métodos ágeis, que promovem a produtividade em pequenas equipes tais como o Scrum e o Kan Ban, e os princípios do XP (Extreme Programming), estes últimos rotulados como dentro do tema “engenharia de software”. Uma arquitetura “engineered”, como parece ser o caso de flow-based programming ou outras técnicas de uso de componentes não são consideradas como alavancadoras da produtividade mas apenas como arquieturas alternativas sem nenhuma qualidade intrínseca para resolver as dificuldades atualmente enfrentadas. O método da força bruta, agora não mais colocando mais programadores mas reduzindo o escopo e as equipes e aplicando uma política draconiana de controle da persecução das tarefas é preconizado. Acredito que flow-based programming vai engendrar uma drástica revisão de todo este cenário.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s