Arquivo mensais:setembro 2023

Radar de Tecnologia

Publicado em por

Uma nova edição do Technology Radar da ThoughtWorks foi publicada ontem

https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2023/09/tr_technology_radar_vol_29_en.pdf

Para surpresa de ninguém, IA é o grande tema desta edição, eu entretanto fui atraído por 2 itens:

Mermaid

Mermaid está no quadrante de adoção.

https://mermaid.js.org/

No meu projeto atual usamos documentação-como-código desde o inicio, exceto que a nossa escolha foi PlantUML. O que eu posso comentar da minha experiência, em 3 aspectos:

  • Consistência: Ao tratar a documentação como código, torna-se mais fácil manter a consistência entre o código e sua documentação, especialmente no que tange à arquitetura de software. Utilizamos C4 e quando fazemos mudanças estruturais, os diagramas e o novo código são versionados no mesmo PR, mostrando exatamente a evolução do sistema;
  • Colaboração: Entre engenheiros é ótimo pois soa mais natural editar a documentação no mesmo fluxo com que o software é editado. Fora do mundo dos engenheiros, há uma barreira pois é necessário saber o markup e uma interface point-and-click é mais intuitiva. Isto fica evidente na discussão do contexto do software, em que é necessária a interação com os colegas de negócio;
  • Automação: Aqui é o ponto em que a documentação-como-código brilha. Se a cultura dos times incentiva comentários no seu codebase, vários diagramas podem ser gerados automaticamente.

Complexidade

Para mim é difícil concordar com o argumento de que devemos abraçar a complexidade em desenvolvimento de software. Complexidade é algo que deve ser combatido no seu design, na sua implementação, no seu processo. Utilizando o Cynefin, nosso objetivo é transicionar do complexo para o complicado e, veja, o artigo utiliza AI como um exemplo de complexidade porém AI opera no complicado, ao utilizar padrões e conhecimento para tomar decisões.

Neste tópico, eu lembro do Dumbledore falando para o Harry: “Soon we must all face the choice, between what is right and what is easy”. O trabalho de um arquiteto, e todos os engenheiros são arquitetos em alguma escala, é resistir à tentação da solução fácil; é comum nestas situações introduzir complexidade acidental. Se estamos falando de complexidade essencial, ok, ainda assim, devemos lutar para diminuí-la. Mas eu não culpo a ThoughtWorks pela abordagem, o Dijkstra já dizia “complexity sells better”.

https://www.thoughtworks.com/en-us/insights/blog/technology-strategy/why-embracing-complexity-real-challenge-software-today

Leiam o Radar, sempre é interessante especialmente confiram o que está próximo do nível de adoção.

APIDays

Publicado em por

Esta semana estive em Londres atendendo o evento ApiDays. Uma vez ao ano eu participo de um evento externo, em adição a estudar sozinho, é importante encontrar colegas de profissão e conversar sobre o que acontece nas trincheiras. Para a minha surpresa, IA não foi o tema central, assisti por volta de 30 palestras e apenas 4 eram especificamente sobre IA. Dois grandes temas no evento:

Governança de API’s: Ênfase dada ao ciclo de vida das API’s: definição->design->desenvolvimento-> testes->publicação->operação. O que eu vou levar para casa:

  • A importância da documentação, ela é o ponto central da sua API, seja ela consumida pelos desenvolvedores, seja ela lida por robôs.
  • O papel dos padrões no design. Este é um mercado em ascensão e seus consumidores esperam que você siga OpenAPI, AsyncAPI, Semantic Versioning, HTTP response codes, Protocol Buffers definition language.
  • Sua operação tem que prever liberdade de escolha, não assuma um cloud provider, não force um gateway.

Democratização de API’s: Aqui há 2 visōes que estão convergindo, por um lado experts dizem que devemos desenvolver as API’s pensando em devops e gitops. Esta visão coloca uma grande importância nos aspectos de governança mencionados no item anterior; em adição, esta visão ressalta interoperabilidade e composibilidade como atributos essencias para API’s modernas. Por outro lado, se olharmos para a composição mais comuma das empresas, apenas 10% são da área de tecnologia (pesquisa da Gartner exibida em uma das palestras); temos 49% de usuários finais e 41% classificados como analistas de negócio tecnólogos. Estes 41% criam soluções de tecnlogia ou de análise a partir das soluções que a área de TI fornece. Eles cunharam o termo ‘mundo da economia pós-API’ para abraçar este pessoal que tem ter acesso facilitado às API’s. Quanto mais simples for, mais fácil será para produtos inovadores surgirem a partir da informação disponível. Esta segunda visão aposta em API’s abertas e públicas, aposta em ecossistemas e marketplaces.

Vou citar 2 ferramentas que testei no evento e achei fantásticas:

Superface.ai: OK, existem catálogos de API’s, sabemos do conceito de observabilidade, como lidar com API’s que são similares porém com formatos diferentes? Pense no wttr.in e no OpenWeatherMap, ambas permitem que você veja se vai chover hoje em Londres. Mas a similaridade termina aí, é necessário fazer o código para cada uma delas. Mais, se uma delas estiver indisponível você é responsável por rotear o pedido. O Superface lida com isto: (1) você fala qual o seu contrato (2) o Superface tem agentes autônomos que descobrem API’s condizentes com o seu contrato e mapeia o seu contrato para o contrato das API’s que ele localizou. (ok, aqui tem IA 🙂)

Mocking servers do Postman: eu uso Postman frequentemente para testar API’s, e descobri que nele você pode prototipar a sua API. Desenhe seus métodos, especifique os contratos a partir de exemplos e o Postman cria a documentação e um endpoint. Quando eu queria pensar em uma API, usava o httpbin, isto é muuuito mais bacana.

Home Office

Publicado em por

Em 2008 eu trabalhava no Itaú na TI de Mercado de Capitais. Era parte de um time responsável por relatórios de performance de fundos, usados pelos traders para guiar suas estratégias. Nosso suporte era 24×7, especialmente durante a madrugada quando estes relatórios eram gerados. Discutimos se seria possível trabalhar em casa para o engenheiro responsável pelo stand-by; nosso pedido foi negado sob a justificativa de que era mais produtivo trabalhar na infra do banco, onde tudo estava disponível e onde todos os engenheiros de stand-by estavam. Veio 2020, Covid e sabemos o resultado: trabalhamos muito bem em nossas casas. Minha experiência e de colegas: trabalhamos melhor em nossas casas.

O Zoom cresceu exponencialmente justamente neste nicho e na semana passada lemos que seu CEO prefere trabalho presencial. Eric Yuan aponta velocidade de inovação e interação como motivadores, entrelinhas leia-se ‘nossa produtividade precisa aumentar’, de novo ela. Também nas entrelinhas eu leio que no Zoom o alto comando não confia nas pessoas exceto quando elas estão por perto para eu ver o que elas estão fazendo. A Microsoft mostrou isto neste Pulse Report de 2022:
“The majority of employees (87%) report that they are productive at work (…)” but “85% of global business decision makers say that the shift to hybrid work has made it challenging to have confidence that people are being productive”.

Trabalho em TI, este é o mundo que eu conheço e sobre o qual posso opinar. Aqui, engenheiros são produtivos trabalhando em casa e há dúvidas no C-level. A McKinsey deu voz a este sentimento e trouxe sua ideia há 2 semanas: Yes, you can measure software developer productivity. Kent Beck escreveu sobre isto na sua newsletter. Dada aquela crise de confiança que eu citei, são propostas métricas para medir o que estou fazendo. Kent é preciso na sua análise, eu concordo: eles confundem “atividade” com “produtividade”. Produtividade é sobre entregar valor e sobre transformar a sua empresa.

A dicotomia trabalho remoto X trabalho presencial não deveria ser a discussão central, confiança e produtividade são os elementais centrais. E ademais, você quer voltar para o escritório todos os dias?