Não há balas de prata, ou há?

Não há balas de prata, ou há?

Nossa área é conhecida por ter evolução rápida da tecnologia, mas quando comecei a trabalhar mais com engenharia de software comecei a perceber que alguns problemas sempre se repetiam. Aos poucos comecei a me interessar por estudos mais antigos sobre o assunto, que aparentemente tratavam de verdades mais essenciais do que o hype da evolução infinita.

Um desses estudos foi o livro “The Mythical Man Month” do ex-programador da IBM Fred. P. Brooks. Em um dos ensaios, escrito em 1984, ele faz uma afirmação corajosa com relação a engenharia de software:

“Não haverá em 10 anos nenhuma tecnologia ou técnica gerencial que permita uma melhoria em sequer uma ordem de magnitude com relação à produtividade, confiabilidade ou simplicidade”.

Lembremos que na época a indústria de hardware estava tendo melhorias de ordem-de-magnitude a cada poucos anos. Por que software não seguiria a mesma lógica?

O artigo foi intitulado “No silver bullet“. Não há balas de prata. A relação é com a imagem de um lobisomem, que justamente nos inspira medo por que transforma uma pessoa conhecida e querida em algo terrível e monstruoso. Algo como o nosso tio que compartilha fake news nas redes sociais. O problema nem é tanto a monstruosidade em si, mas puxa, logo você tio?

O que isso tem a ver com projeto de sistemas? No começo eles parecem simples e diretos. Programadores ficam naturalmente animados com novos projetos e desafios. Com o passar do tempo o projeto pode se tornar um inferno de entregas atrasadas, orçamento estourado e bugs que se multiplicam. Quem nunca?

Brooks descreve o problema explicando que a complexidade de um sistema pode ser dividida em duas categorias: dificuldades essenciais e acidentais. Dificuldades acidentais são aquelas fáceis de resolver: liguagens de programação burocráticas, computador lento, ambiente de programação ruim, falta de café, etc. O argumento central do autor é que mesmo que você zere esses problemas as dificuldades essencias ainda serão mais relevantes. 

Dificuldade acidental

O autor considera que as dificuldade essenciais são a especificação e projetos corretos, assim como o teste desta construção conceitual e não o trabalho de codificar e testar a fidelidade dessa representação abstrata.

As essências dessas dificuldades, em resumo, são:

Complexidade: Softwares podem ser mais complexos do que qualquer coisa que um ser humano já tenha construído. A principal diferença da área de engenharia tradicional é que em software não há nenhum componente que se repete. Estes componentes interagem entre si e aumentam de complexidade de forma não-linear com o aumento de componentes.

Conformidade: O software nunca nasce sozinho. Necessariamente você vai fazer alguma interface que não é de sua responsabilidade, e isso pode adicionar uma complexidade arbitrária. Em 1984 haviam os mainframes com uma arquitetura esquisita. Hoje temos as interfaces com outras máquinas ou instituições do governo. Quem já implementou emissão de cupom fiscal em uma impressora bematech e sobreviveu para contar a história sabe do que estamos falando.

Mudança: Ninguém tenta adicionar uma nova porta em um carro depois que ele está na linha de montagem. Com software isso é possível, ele é infinitamente maleável.

Invisibilidade: Software não pode ser representado no mundo físico. Já tentou fazer um diagrama de classes de um sistema de média complexidade? Acredito que no segundo ano de profissão já abandonamos esses tipos de diagrama com excessão das primeiras etapas de desenvolvimento. Qualquer diagrama de um software vai resultar em um conjunto de grafos sobrepostos que não podem ser representados no papel.

Conformidade

O autor apresenta algumas ideias para atacar a essência dessas dificuldades. Algumas hoje já são bem conhecidas e na época eram apenas esperanças como: prototipagem rápida, desenvolvimento incremental e poucas e boas cabeças responsáveis pela arquitetura.

Porém, o que ele descreve como a melhor abordagem para evitar a complexidade da construção de um software é… (rufem os tambores) não construí-lo!

Lembremos que na época a indústria de software “de prateleira” estava na sua infância. O Atari 2600 tinha 2 anos de vida. Muitas empresas que podiam pagar por grandes computadores ainda desenvolviam suas próprias soluções dentro de casa. O conceito de comprar um software pronto era radical se sua necessidade fosse um pouco maior do que uma planilha de dados. Ainda assim, Brooks previu o desenvolvimento deste mercado como a “mais profunda tendência de longo prazo em engenharia de software”.

De fato, ele estava certo. Pelo simples fato de que adquirir um software pronto resulta em custo em ordens de magnitude menor do que construí-lo, com disponibilidade imediata e com melhor documentação e manutenção do que o software construído em casa.

Brooks já havia previsto também a construção do software em módulos, onde você pode construir artesanalmente o mínimo possível, e acoplar os módulos adicionais quando necessário. O que Brooks não poderia ter sonhado foi a evolução do software como serviço (SaaS) que torna isso muito mais fácil. Para que implementar seu próprio servidor de email, emissor de boletos ou de notas fiscais se você pode se associar a empresas especialistas neste assunto?

Talvez seja essa dificuldade inerente de criar software que faça com que muitos desenvolvedores migrem para a área de gestão. Criar software não é para os fracos de coração, por isso que qualquer ajuda é muito bem vinda. Então, antes de construir algo e enfrentar o lobisomem, pergunte-se: eu preciso mesmo?

Referências

Utilize uma API para emissão de documentos fiscais eletrônicos

Nota Fiscal eletrônica é assunto sério e pode dar muito trabalho para seu time de desenvolvimento. Mas você não precisa se preocupar e nem ter um custo alto para terceirizar a emissão destes documentos. A Focus NFe é uma plataforma especializada em documentos fiscais. Atua no mercado desde o surgimento desta tecnologia. Empresas de todos os portes já emitiram mais de 11 milhões de documentos fiscais.

Veja abaixo a lista de todas as APIs disponíveis na Focus NFe

  • NFe: Emita Nota Fiscal Eletrônica
  • NFSe: Nota de serviço com um formato único e simplificado
  • NFCe: Nota ao consumidor
  • CFe SAT: Em SP? Sem problemas, temos integração com SAT também.
  • CTe: Conhecimento de transporte eletrônico (inclusive CTe OS)
  • MDe: Receba por webhooks todas as notas emitidas para o seu CNPJ

Além de APIs acessórias úteis para o seu software.

  • CEP: Busca de CEPs sempre atualizada com a base de dados dos Correios
  • CFOP: Consulte todos os códigos fiscais de operação
  • NCM: Mantenha o cadastro de produtos de seu cliente sempre correto com o código NCM padronizado