Informática: fichamentos / clippings / recortes de não-ficção.
Nonfiction Litblog.
Curador é Mestrando em Computação, Especialista em Governança de T.I., Tecnólogo em Redes, Técnico.
Informática: fichamentos / clippings / recortes de não-ficção.
Nonfiction Litblog.
Curador é Mestrando em Computação, Especialista em Governança de T.I., Tecnólogo em Redes, Técnico.
Resumo da Palestra Engenharia de Software no Séc. XXI: Conquistas e Desafios. Palestrante: Marco Túlio Valente, servidor da UFMG desde 2009, tendo trabalhado anteriormente na TeleMiG. Autor de um livro: “Engenharia de Software Moderna: princípio e práticas para desenvolvimento de software com produtividade”.
Marco defende que o software mudou o mundo, devido ao seu impacto em bancos, comércio, mídia, educação, moeda, conferências, entre outros. Sendo software uma atividade intensiva em capital humano, Marco conclui que os Engenheiros de Software ajudaram a mudar o mundo. Resta saber o que mudou no desenvolvimento de software nas últimas duas décadas.
Recapitulando a história dos modelos de desenvolvimento de software, Marco conta que os resultados do modelo cascata, muito comum nas décadas de 1990 e 2000 não foram nada bons: projetos atrasavam muito, eram cancelados, estouravam os orçamentos. A razão para isso, alega, é que software é muito diferente de qualquer produto físico, e, por isso, copiar princípios, técnicas, métodos e modelos de outras engenharias para aplicar na Engenharia de Software não tem como dar certo mesmo.
Reconhecido isto, foi um passo natural a mudança do modelo em cascata para o modelo ágil, no começo do século. A agilidade não foi inventada, e sim descoberta: uma cultura emergiu e foi se consolidando, sem que se possa atribuir ao nome de alguém específico. Afinal, quando um projeto em cascata estava naufragando e era preciso livrar a cara de não conseguir entregar o produto, formava-se um grupo de emergência para tentar entregar uma primeira versão incompleta. Este já era o embrião dos métodos ágeis, por ser uma forma de versões incrementais.
Hoje em dia, entre as empresas de desenvolvimento de software brasileiras, 87% usam métodos ágeis, enquanto apenas 6,5% usam cascata (pesquisa de 2020).
Agilidade define-se como a capacidade de aprender e gerar valor de modo contínuo: aprender sobre o cliente e gerar valor na forma de resolução de problemas usando software. Isso pressupõe releases frequentes, que pressupõe integração contínua, que pressupõe testes automatizados, que pressupõe arquiteturas desacopladas, que pressupõe squads (times desacoplados), e assim por diante – a arquitetura emula a organização dos times. Com uma coisa levando à outra, agilidade é mais do que os processos (XP, Scrum, Kanban) e as práticas (testes, refactoring, integração contínua) envolvidas.
Se o software mudou o mundo, e a agilidade mudou a forma de fazer o software, então a agilidade mudou o mundo. Marco Túlio acredita que agilidade é o fim da história: não haverá pós-agilidade, pois, sendo o modelo mais adequado para o mundo digital, pessoalmente acredita que não haverá uma total mudança em relação a este modelo, apenas melhorias incrementais.
Outra transformação significativa, embora menos reconhecida, na área de desenvolvimento de software foi a mudança do foco, de “projeto” para “produto”. Os projetos (feitos no MSProject mesmo) tinham duração finita, e destinavam-se a uma atividade-meio da empresa, enquanto hoje em dia software é principalmente atividade-fim, com duração infinita. O software tornou-se a alma da empresa, se confundindo com ela, é a razão de existir dela. Zoom é um software e uma empresa. Seu desenvolvimento nunca vai terminar, ao menos não enquanto a empresa existir. Assim como Zoom, são também produtos: Inter, Finbits, Hotmart, iFood, Uber, Spotify, Discord, etc.
Isso muda, do ponto de vista técnico, algumas coisas relevantes: qualidade se torna mais importante, pois só um louco não cuidaria da qualidade do produto, que é a atividade-fim; executivos de tecnologia têm assumido cargos de CEO, devido à digitalização da economia, fato que aumentou a importância do TI nas empresas; “requisitos” não faz muito sentido quando o centro da evolução do produto é o cliente, pois “99% do aprendizado acontece após o lançamento”, fazendo com que requisitos não passem de hipóteses que podem ir se validando ou não – através de técnicas/métodos extremamente importantes, como Design Thinking, Jobs to be Done, Discovery, MVPs, Testes A/B.
Marco Túlio acredita que o maior desafio existente hoje é o descasamento entre oferta e demanda de Engenheiros de Software, com demanda muito maior do que a oferta e as empresas desesperadas para contratá-los – o que contrasta totalmente com a realidade de desemprego na economia do mundo todo. Alega ser um problema global, brasileiro e complexo – não fosse complexo, já teria sido resolvido, é claro. A complexidade advém do fato de que não é simples formar Engenheiros de Software, não só pelas dificuldades inerentes ao tema, mas pela necessidade de um conjunto amplo de habilidades. Adicionalmente, não é possível agilizar a formação “pulando etapas”, pois há bases de fundamentos de programação e de computação superimportantes, há parte teórica e parte prática, há soft skills e habilidades de negócios – as empresas contratam por causa das hard skills e demitem por causa das soft skills. Como toda empresa está se tornando uma empresa de software, a Engenharia de Software cada vez mais exige conhecimentos de negócios também.
Embora não seja possível ‘formar milhares de engenheiros de software em 6 meses’ (“não há bala de prata”), o palestrante acredita que é possível ter muitas melhorias incrementais na área de educação de Engenharia de Software, pois algumas poucas coisas ainda conseguem ter um grande impacto (“o oceano mais azul que já vi na minha vida”).
Mauricio visou, nessa palestra, em passar uma visão do mercado de trabalho para nós acadêmicos. Ele é uma pessoa que se mudou para a Holanda para ser pesquisador, mas que acabou indo novamente parar na iniciativa privada. Sua carreira foi uma sucessão de ‘cavalos encilhados’ bem aproveitados, sem um grande plano prévio. Por isso, ele adquiriu um aprendizado prático que a Academia não tem como passar, mas que ele pôde passar em parte de volta para a Academia:
As empresas existem pelo negócio, não pelo código
Tudo numa empresa visa fazê-la crescer: todas as decisões de Engenharia de Software em uma empresa que usa essa ciência e que é tech-first são tomadas para fazerem a empresa crescer. Ninguém toma uma decisão de Engenharia de Software por ser uma Best Practice, ou escreve testes por isso ajudar a achar bugs, ou vão migrar para microsserviços por parecem legais e parecem escalar. Sempre tem uma decisão de negócios por trás das decisões de software.
Assim, por mais primorosa que seja a ferramenta que você criou, enquanto pesquisador, para o fim a que se propôs, nenhuma Engineering Board de nenhuma empresa irá adotá-la, ou financiar sua pesquisa, se você não mostrar o que isso vai melhorar pra ela a partir do ponto de vista do negócio. Num exemplo fictício, uma ferramenta que encontra bugs pode não ser útil, pois nem todos os bugs são importantes o bastante para precisarem de solução, e rodar a ferramenta requer uma equipe, o que consome recursos (tempo, dinheiro, mão de obra) que seriam melhor investidos em outra coisa. A princípio, não adotar Best Practices parece um contrassenso, já que elas existem para tornar tudo mais fácil, mas esse exemplo ilustra como Best Practices, por si só, não são relevantes para empresas.
Riscos demasiado grandes não são bem recebidos
Outra questão bastante pragmática é que nenhuma empresa de tecnologia irá fazer mudanças drásticas gigantescas (“big bang changes”), não importa quão melhor o software ficaria da nova forma proposta. Algo assim sequer será levado em consideração. A razão é simples: a probabilidade disso dar errado e quebrar algo no mundo real é muito grande para que alguma empresa seja imprudente e se arriscar a tal ponto. Por exemplo, um líder do Google já disse publicamente que uma ferramenta que crie um merge request que queira tocar 30.000 classes de uma só vez vai ser completamente ignorado pela equipe.
Portanto, quem estiver desenvolvendo uma ferramenta para “tornar o mundo melhor” deve levar em conta o funcionamento do mundo: as mudanças têm que ser feitas de parte em parte, gradualmente, pequeninas, e a ferramenta tem que permitir ser rodada de pouco em pouco nas mãos dos times de software. Nada de “big bang refactoring”.
Tempo é dinheiro, mas a pressa é inimiga da perfeição
Para o negócio, entregar valor para o cliente logo é mais importante que usar boas práticas ou fazer código bonito. Se um desenvolvedor tiver que levar um mês para implementar direito uma funcionalidade, mas tiver uma gambiarra como atalho para implementar ainda hoje, ele escolherá a gambiarra. Cabe à Gerência de Projeto a responsabilidade de achar uma forma pela qual o desenvolvedor entregue valor, mas, ao mesmo tempo, mantenha o sistema testável, livre de bugs, e com qualidade de código.
Um grande desafio do mundo real hoje é justamente equiparar o preço de escrever código certo e o de escrever gambiarra, para que a gambiarra não valha a pena, pois os desenvolvedores não vão parar para arrumar a bagunça a cada funcionalidade que tiver de ser implementada, tendendo então a situação a piorar muito ao longo do tempo. Então seria bem vinda pesquisa sobre meios e ferramentas melhores para aferição de apodrecimento de código, que, por sinal, acontece muito rapidamente.
Um problema relacionado é que, numa base de código infinitamente grande, os desenvolvedores terão um comportamento previsível de que, quando desafiados a implementar uma nova funcionalidade, eles olhem a base de código, vejam o que já foi feito no mesmo sentido, e duplicar pelas razões de que: economiza tempo, e funciona. Não é sensato reinventar a roda todos os dias, mas duplicar ideias ruins é realmente problemático. A cópia de trechos de código não é tão problemática quando a cópia de ideias mal elaboradas de mais alto nível, digamos, por problemas de comunicação entre os times.
Engenharia de Software inclui Gestão de Pessoas
Fala-se muito em escalabilidade, mas, no mundo real, esse problema não existe muita dificuldade de escalabilidade tecnológica fora de problemas bem específicos, como o Google. O problema real é a empresa crescer o time de desenvolvimento de uma dezena para centenas de pessoas e manter os processos funcionando satisfatoriamente, pois os canais de comunicação ficam muito mais complexos e a cultura muda. Há também a questão de Onboarding: como introduzir novos membros na equipe, se deslocar membros produtivos para tutorar os novatos reduz a produtividade dos veteranos?
A título de exemplo, a Adyen tem 800 desenvolvedores espalhados pelo mundo, e já é considerado dobrar esse total. Na Engineering Board desta empresa, quase toda reunião é mais sobre pessoas do que sobre tecnologia. Infelizmente, Engenharia de Software Social é um problema fundamental que tem sido estudado bem pouco, e até mesmo desconsiderado abertamente por pessoas proeminentes da área de Engenharia de Software como tema alheio a esta ciência.
Legado existe e você terá que lidar com ele
Toda empresa, no mundo real, tem código legado, e isso não é um sinal ruim. Não há ferramentas para manter o código limpo sempre, e, se restou código legado, pode ser uma empresa grande que teve um crescimento bastante rápido (um bom sinal), cujos custos para migrar sejam altos demais para valer a pena. Então tudo que um pesquisador faz tem que funcionar com código que saia um pouquinho do padrão, por causa de algum componente legado.
Mais do que isto: pode ser legado em ideias, e não em código. São requisitos então, para trabalhar em parceria com uma empresa: entender de tecnologias um pouco mais antigas, ir com a cabeça aberta, e ter disposição a customizar um pouco a solução para que a ferramenta funcione lá.
Testes automatizados não garantem qualidade
Mauricio adora testes automatizados, mas esse é só um dos mecanismos para garantir qualidade. Na escala de Facebook e Adyen, sequer é o mecanismo principal. Feature flags, deploy parcial e monitoramento são bem mais relevantes na prática, na escala mencionada. Tanto a Adyen quanto o Facebook, por exemplo, marcam atualizações para serem liberadas a apenas um pequeno percentual de usuários, e inicialmente apenas os mais geograficamente próximos às sedes destas empresas, a fim de facilitar que os funcionários possam caminhar até o local para resolver pessoalmente, se preciso for. Quanto ao monitoramento, sempre haverá bugs e sempre será preciso observá-los, pois não não dá para prevê-los todos, e é desejável saber o mais rápido possível o que está acontecendo.
O que faz sucesso na Academia não faz no mundo real
Quem vive na bolha do Twitter da Academia sabe que é preciso ter complexidade no paper para o revisor ver algum valor no que você fez e as convenções te aceitarem. Algo como “mostrar serviço”. No mundo real o contrário é que acontece: é muito difícil vender soluções complexas para Engineering Boards, pois soluções simples porém eficazes são as mais fáceis, menos custosas e menos arriscadas de implementar e de explicar para os desenvolvedores.
Devido a isto, pesquisadores que queiram causar impacto no mundo real, como Mauricio, devem fazer um trabalho interno de aceitação de que não irão ser aclamados em convenções acadêmicas, e que os problemas mais relevantes a serem resolvidos não necessariamente são os problemas da área preferida do pesquisador.
O casamento entre as necessidades das empresas e a pesquisa sendo realizada pode passar por encontrar um nicho certo, achar uma empresa que tenha interesse na sua solução. E, por achar uma empresa, entende-se ter um diálogo honesto, conhecendo empresários em eventos do ramo e ir conversando ao longo do tempo para entender os problemas deles, não só disparar e-mails em massa (spam) anunciando para as empresas o que você criou. O trabalho é ao contrário: primeiro conhece-se o problema, depois cria-se a solução, não como se faz, de primeiro criar a solução e depois procurar uma empresa que tenha aquele problema para ser resolvido. Também não funciona tentar forçar sua solução nos seus 3 parceiros industriais só por eles serem os mais próximos de ti.
Existe uma falha atualmente na Academia que é criar muitas ferramentas voltadas para big techs e ignorar as medium techs. Papers em conferências muitas vezes não são aceitos pois a ferramenta foi testada em “empresinhas” de 15 devs da cidade do pesquisador, e não na maior empresa do mundo. Ocorre que existem muitas empresas de médio porte no mundo todo, então soluções para elas não deveriam ser consideradas sem impacto. Ao mesmo tempo, mesmo que você encontre um problema real em uma grande empresa, digamos, no Google, eles NUNCA irão comprar sua solução, mesmo que de fato lá não esteja tudo da melhor forma possível, pela simples razão de que, estando tudo funcionando do jeito atual, a ferramenta não se mostra necessária na prática.
I noticed that SpringerLink article citations that are downloaded, on the RIS format, don't include the article's Keywords, while Scopus and ScienceDirect exported results do include the article's Keywords.
Not having the Keywords turns the citations less useful when imported to third-party tools that provides support to academic research, like Parsifal, because the Keywords are very helpful on the "Study Selection" step of the "Conduction" phase of the Systematic Literature Review, when the researcher needs to judged correctly if an article is relevant or not for the Review s/he is doing.
Do Springer have plans to improve the RIS files generated by SpringerLink in order to make them export the Keywords of each article?
June 25, 2023.
From: customerservice@springernature.com
Thank you for contacting Springer Nature.
I have reviewed your query which needs the involvement of another department; I have therefore escalated it to the relevant team and they will follow-up with you as quickly as possible.
Julu 20, 2023.
From: customerservice@springernature.com
Thank you for contacting Springer Nature.
Hopefully, this will be taken into account in the near future, as the various teams that work on citations for SpringerLink articles are undoubtedly striving to constantly improve.
In the meantime, we appreciate your patience and understanding as we strive to provide the best possible experience for our users. Rest assured that your feedback has been duly noted and will be taken into account during future updates and enhancements to our citation system.
I noticed that SpringerLink search results can only be downloaded on the CSV format, while Scopus and ScienceDirect results can be exported to multiple formats, including BibTeX.
Do Springer have plans to add support for the BibTeX format too?
January 14, 2024
To: customerservice@springernature.com
Good morning again.
I got no answer on this matter.
Did you people on SpringerLink received this email, or maybe it was lost to the spam folder?
March 13, 2024
From: customerservice@springernature.com
Thank you for contacting Springer Nature. Unfortunately, we do not provide plans to add support for the BibTeX format.
I noticed that SpringerLink search engine has only 2 extreme options regarding scope:
search for the entered terms only on the article title, or
search for the entered terms on the whole article text (including the references section),
while Scopus and ScienceDirect search engines do provide the option to search on the scope 'title, abstract, and keywords'-only.
While "title only" is evidently too limiting for well-written Search Strings using boolean operators to express relationships between keywords, and between keywords and its synonyms. I empirically confirmed that searching on "whole text" gives a MASSIVE amount of false positives.
In my research, which used the Search String quoted below, 90,81% of the articles returned by SpringerLink search engine had the keywords searched located:
only on the article text body, which indicates just a brief mention by the author(s), but not a profound study of the topic being researched by the reviewer; or even
only on the reference section, which is even worse, since this is equivalent to attesting that the possibly relevant article is another one and not the one returned by SpringerLink search engine results.
It is like a store informing its address on its website, and the customer walking to the place just to find the door closed with a sign of "moved to address Y". Why do that instead of giving a more precise information?
Search String used:
("drought forecast" OR "drought prediction") AND ("Machine Learning") AND ("drought index" OR "drought indices" OR "precipitation index" OR "precipitation indices") AND ("accuracy" OR "metric")
Again, just to make it clear... Total of articles that did not match these criteria on 'title, abstract or keywords', but insted on 'text body or reference sections': 90,81%. I don't think that a rate of 90,81% of false positives is reasonable for a search engine. Do you think it is?
Do Springer have plans to add support for searching on 'title, abstract, and keywords'-only?
June 25, 2023
From: customerservice@springernature.com
Thank you for contacting Springer Nature.
I have reviewed your query which needs the involvement of another department; I have therefore escalated it to the relevant team and they will follow-up with you as quickly as possible.