Você já ouviu falar de uma equipe de desenvolvimento de software que não precisaria enfrentar uma dívida técnica?
Eu também não. Além disso:
Os engenheiros gastam cerca de um terço do tempo em dívidas técnicas, o que reduz o moral das equipes e custa às empresas cerca de 85 bilhões de dólares anualmente.
Faixa de Estudo
Apenas pense sobre isso. São 85 bilhões de dólares.
Um terço de todo o tempo que os desenvolvedores gastam em dívidas técnicas. Isso enche os desenvolvedores de horror. Essa é, de fato, a pior parte de seu trabalho - e o fato de o restante dos negócios muitas vezes não sentir empatia por eles acrescenta combustível ao incêndio. Não há ninguém para culpar, mas a dívida técnica é universalmente subestimada. Por causa disso, as empresas de software ficam lentamente rígidas, até perder a capacidade de crescer, o que não requer meses e anos para reescrever seus aplicativos do zero ... e esse tempo no mercado hoje é uma eternidade.
Dívida técnica é um fenômeno comum, certo? Começamos a escrever código, o aumento da dívida técnica e o boom , que de repente se torna demais. Nossa base de códigos está atolada e chegamos à falência técnica. Portanto, estamos brigando com ele. Atendemos uma necessidade dolorosa e pagamos parte da dívida. Às vezes conseguimos, outras não. Essa é a essência do desenvolvimento de software. Então, temos tudo organizado.
Mas deveria ser assim? Existem leis fundamentais do desenvolvimento de software responsáveis por isso? E, se sim, podemos usar essas leis para nosso próprio benefício? A dívida técnica é comum, mas não deve ser falência técnica.
Vamos recorrer a vários campos da ciência para obter algumas dicas, porque as leis da termodinâmica podem nos dar idéias importantes para entender por que a dívida técnica é inevitável.
Macrotrends torna inevitável dívida técnica
A primeira lei da termodinâmica
Também conhecida como lei da conservação de energia ; afirma:
A energia total do sistema fechado permanece constante; Dizem que persiste com o tempo.
Em outras palavras, a energia não pode ser criada ou destruída, no entanto, pode ser transferida de uma forma para outra.
Se sem dificuldades desnecessárias, vamos pensar em nossa base de código como um sistema fechado . Descartamos dependências externas e tudo o que vive fora de nossa base de códigos. Sob essas condições, há um número inalterado de desenvolvedores, o desenvolvimento de recursos em um ritmo consistentemente alto - a quantidade de entropia (uma medida de desordem e aleatoriedade no sistema ) em nossa base de código permanece constante.
Nossos desenvolvedores não podem se tornar super-homens em uma noite; portanto, não podemos aumentar sua eficácia se eles já derem o melhor. Mas podemos contratar mais desenvolvedores, e isso aumenta a energia em nosso sistema. É por isso que a lei de Brooks é verdadeira: "Se um projeto não cumprir os prazos, adicionar mais mão-de-obra atrasará ainda mais" - porque aumenta a energia ou o caos em um sistema em que o caos já é grande.
Empresas de software em rápido crescimento lutam com esse poder o tempo todo. Eles aumentam uma rodada de investimentos, dobram o tamanho da equipe de desenvolvimento o mais rápido que o mercado de trabalho permitir e, em seguida, precisam lidar com um grande salto em "energia" em sua base de códigos. Isso geralmente excede as capacidades da empresa e pode levar a um aumento acentuado da dívida técnica, caso não sejam tomadas medidas preventivas urgentes.
Mas espere um momento. Por que isso leva a um aumento da dívida técnica?
A segunda lei da termodinâmica
A desordem em um sistema fechado não pode diminuir; só pode permanecer inalterado ou aumentar.
De fato, os sistemas fechados entram em um estado de maior desordem de maneira natural. Esse "distúrbio" - que chamamos acima de "energia" ou "caos" - é chamado entropia. Ivar Jacobson e seus colegas investigaram o fenômeno da entropia em bases de código e introduziram o termo entropia de software . À medida que você faz alterações na base de código, sua entropia aumenta. Esse caos crescente é a causa da dívida técnica.
De volta à nossa empresa de software em rápido crescimento, cuja base de clientes continua a se expandir e o mercado está crescendo. Sua crescente equipe de desenvolvimento apresenta recursos dia e noite para acompanhar o crescimento. Se você não fizer nada, a base de código ficará mais confusa. A pressão está aumentando.
Eu vejo a dívida técnica como entropia na base de código. Eu não acho que ele irá desaparecer, a luta com ele será constante.
Ron Pragides , vice-presidente de engenharia da Carta
Ao planejar cada sprint, nossa empresa enfrenta uma escolha: há algo que você precisa fazer para reduzir a crescente complexidade ou vale a pena desenvolver e fornecer novos recursos?
A terceira e última lei da termodinâmica esclarece por que esse dilema não corresponde nem de perto ao verdadeiro estado das coisas.
Terceira Lei da Termodinâmica
A entropia do sistema atinge um valor constante quando a temperatura é zero absoluto.
Parece complicado, mas, na realidade, é bastante simples em essência e, embora as leis da termodinâmica tenham conseqüências de longo alcance (e às vezes simplesmente esmagadoras), seus fundamentos são fáceis de entender. Por exemplo, quando a água assume a forma de vapor, suas moléculas ficam "livres" para se moverem de maneira completamente caótica. Entropia está em toda parte. No entanto, quando a água congela, suas moléculas são "trancadas" e permanecem no local (mais ou menos). A entropia diminui e atinge um valor constante.
Então, o que podemos fazer para controlar a entropia de software?
Bem, poderíamos parar de desenvolver um novo código. Por esse motivo, algumas equipes gostam de "congelar" o código para testar completamente seu sistema antes de liberá-lo para os clientes. Se a base de código não muda mais, a entropia não aumenta, o caos também, não há mais conseqüências imprevistas e a dívida técnica não aumenta.
No entanto, é impossível manter o código congelado para sempre - precisamos de novos recursos. Portanto, a única opção que resta para nós é refatorar.
O processo de refatoração de código pode ajudar na eliminação gradual da entropia de software.
Wikipedia
Uma extensão gratuita para o VSCode para ajudá-lo com isso . Comece agora antes que tudo saia do controle!
Reduzir a entropia de software não é fácil
Até agora tudo bem. De fato, tudo isso parece uma afirmação do óbvio; quem já ouviu falar sobre desenvolvimento de software está familiarizado com tudo isso, pelo menos intuitivamente.
Por que a dívida técnica ainda está nos pegando de surpresa?
Isso ocorre porque, embora saibamos da necessidade de refatorar o código para reduzir a confusão, ainda existem inúmeras outras forças que prevalecem sobre nós que nos impedem de alocar o tempo e os recursos necessários para fazer a refatoração corretamente e com frequência suficiente. Isso significa que, tanto na nossa como em todas as outras bases de código, a entropia do software está em constante crescimento.
Todos conhecemos a lei de Moore, mas pense na versão de Bill Gates da lei de Wirth :
A velocidade do software diminui pela metade a cada um ano e meio.
Bill Gates
Estou convencido de que a crescente entropia de nossas bases de código é a principal força motriz por trás desse padrão.
A taxa de crescimento da entropia de software está diretamente relacionada às taxas de crescimento de fatores como tecnologia, mercados de software, empresas de software e alfabetização de código - e cada um deles cresce rapidamente.
Fonte: O Futuro Emergente
Imagine a pressão que essas expectativas colocam nas equipes de desenvolvimento de software. Essas são tendências globais sérias e podem ser sentidas como esmagadoras por um grupo relativamente pequeno de pessoas. É quase como pedir para que superem a gravidade e decolem, agitando os braços.
Imagens reais de uma equipe de desenvolvedores que lutam contra dívidas técnicas
No próximo artigo, consideraremos microtendências que constantemente nos levam à falência técnica, bem como a maneira como as empresas de software em rápido crescimento podem combatê-las. Fique conosco!