Crescente dívida técnica em pequenas empresas de software indianas que desenvolvem aplicativos e sites: quem é responsável por isso?

Estou na indústria indiana de serviços de software há 10 anos e, durante todo esse tempo, vi bons projetos serem concluídos e fazerem maravilhas. Já vi equipes esqueléticas trabalharem incansavelmente em condições agonizantes para construir produtos que foram amados por pessoas do outro lado do planeta. E embora tenha havido ótimas lembranças nesta década trabalhando em alguns projetos maravilhosos, também testemunhei projetos indo ladeira abaixo e produtos de software dando errado devido a vários motivos. Aconteceu mais vezes do que eu desejaria ao meu redor e em torno de pessoas que conheci ao longo desses 10 anos.

Muito se tem falado sobre projetos dando errado. Os memes fervilham na internet sobre como toda a hierarquia persegue uma à outra como uma cadeia alimentar nas selvas. Algumas pessoas culpam os programadores por escreverem códigos com erros, enquanto outras amaldiçoam a administração por fazer promessas impraticáveis ​​que são impossíveis de cumprir. Algumas pessoas até culpam os clientes por não entenderem os pré-requisitos técnicos e as dependências dessa indústria. Mas quase não ouvi ninguém falar sobre Dívida Técnica, ou Dívida Código, e lidar com essa questão de forma civilizada, sem apontar o dedo uns para os outros. Nem uma vez me deparei com este termo de dívida tecnológica de pessoas ao meu redor, ou dos eventos que participei, ou dos blogs locais que li.

Só me deparei com esse termo quando li blogs e periódicos do Vale do Silício, nos Estados Unidos. Isso significa que a maioria dos programadores e executivos de software que trabalham em pequenas e médias empresas de desenvolvimento de software na Índia nunca ouviram falar desse termo até agora. Então, deixe-me começar explicando o termo em si. Dívida técnica ou Dívida de código é um conceito no desenvolvimento de software que reflete o custo implícito de retrabalho adicional causado pela escolha de uma solução fácil (limitada) agora, em vez de usar uma abordagem melhor que levaria mais tempo.

Deixe-me dividi-lo para torná-lo simples. É um conceito para calcular o custo de resolver problemas de programação e design que podem ter aumentado devido à escolha de uma opção fácil de construir um módulo específico ou um sistema inteiro, em vez de escolher o melhor e mais eficiente método de construí-lo. No campo do desenvolvimento de software, esse fenômeno de sua preguiça e atraso voltando para mordê-lo na bunda acontece com muito mais frequência do que em qualquer outro lugar. É quase como se o Karma tivesse uma representação social de ser mal-intencionado pelos programadores.

Por favor, não me entenda mal, não estou culpando os programadores por toda a dívida de código. Certamente existem várias entidades responsáveis ​​pela dívida de código que surge com certeza em mais de 90% dos projetos em empresas de desenvolvimento de software de pequeno porte na Índia. Deixe-me tentar cobrir alguns deles brevemente:

1. CLIENTES IMPACIENTES E SUPER INTELIGENTES

Sim, vou começar por morder a própria mão que alimenta e fazê-lo impiedosamente. O mercado de projetos terceirizados de desenvolvimento de software de pequeno porte é enorme e altamente fragmentado. Existem empresas genuinamente boas que justificam perfeitamente esse mercado globalizado, enquanto outras são apenas empresas parasitas que se alimentam desse arranjo perfeitamente bom apenas porque não é regulamentado e não controlado.

Isso leva os clientes a cometer um erro ao escolher a empresa certa para fazer parceria com base em suas necessidades. Embora não ter habilidades adequadas de verificação não seja culpa deles, mas não há ninguém para culpar por eles não terem inteligência básica na identificação de uma empresa de lixo de uma genuína. Agora, uma vez que eles concordam em seguir em frente com uma equipe pouco talentosa, eles sufocam suas expectativas irreais e sua linha do tempo. Não só isso, alguns deles até exageram e mostram como são inteligentes trazendo suas próprias sugestões de design e programação. (#noallclients)

Se você já foi cliente de uma empresa de desenvolvimento de software, peço humildemente que os deixe em paz e permita que eles façam seu trabalho. Tente ir a um médico ou advogado e diga a eles o que você pesquisou no Google e o que disse sobre seu problema e veja a reação em seus rostos. Nenhum especialista em seu campo gosta de ser aconselhado sobre seu próprio campo por um noob. Os engenheiros de software não são exceções.

Se você encontrar uma boa equipe de desenvolvimento de software e eles parecerem promissores, dê a eles espaço e eles não sentirão o desejo de cortar custos, o que resultaria em menos dívida de código em seu projeto. E adivinhem, na maioria das vezes, são vocês, os clientes que pagam essa dívida de código. Já ouviu falar nas palavras: “Solicitação de mudança”? Aposto que a maioria de vocês tem! Em um cenário ideal, você nunca deveria ouvir essas palavras em sua vida. Mas isso raramente acontece. E quanto mais vezes você ouve essas palavras, mais você se ferra por ser cliente de uma empresa de software.

2. GERENTES PREGUIÇOSOS E DIVERTIDOS

Quando digo gerentes aqui, é qualquer pessoa na posição de gerenciamento de projetos do lado da empresa de desenvolvimento de software. Seja um gerente de projeto, um líder de equipe, um chefe de entrega ou um proprietário de empresa, se você já tentou lavar as mãos de um projeto rapidamente apenas para encerrá-lo e receber seu pagamento, você é uma parte também culpados por essa dívida tecnológica em seus projetos.

Embora a parte mais triste aqui seja que vocês nunca devem pagar a dívida de tecnologia. Ou é o cliente pagando por isso usando um produto abaixo do padrão, ou realmente pagando mais dinheiro para limpá-lo. E se não é o cliente, são os programadores pobres que pagam por isso, tendo que trabalhar horas intermináveis ​​muito além do que eles são obrigados a fazer. Mas quase nunca são esses caras do meio, portanto, de acordo comigo, eles devem ser as entidades mais responsáveis ​​nesse tópico de dívida de tecnologia.

Se você estiver contratando um deles, a maior qualidade que eles devem ter é a moralidade. Se sua bússola moral estiver apontando na direção certa, eles assumirão a responsabilidade e tomarão a decisão certa a favor do projeto, o que acabaria levando a menos compilação de dívidas tecnológicas. Isso me lembra aquela famosa citação de Jack Ma onde ele falou sobre escolher trabalhar para o líder certo. Muito apto neste cenário aqui.

3. PROGRAMADORES

Ah sim, eu não terminaria este tópico culpando vocês também! Mas ei, #notodosprogramadores, certo? Bem, sim, mas quase 94% dos programadores. Pelo menos é o que pensa CP Gurani, CEO da Tech Mahindra, quando fez a chocante revelação há alguns anos de que 94% dos graduados em TI não são aptos para o trabalho. Não sei exatamente como ele chegou a esse número, mas sendo um produto das faculdades de engenharia indianas e tendo testemunhado todo o ecossistema de engenharia de TI nos últimos 10 anos, posso dizer que tendo a concordar com o que o Sr. Gurani afirmou.

Não estou tentando debater se é 94%, 90% ou 80%. Mas para fazer uma analogia, quase todos nós sabemos que precisamos de farinha, água e uma pitada de sal para fazer a massa e um rolo para fazer os chapatis. Mas muito poucos de nós podem realmente fazer chapatis comestíveis. É um processo simples, mas ainda requer um pouco de talento e muita prática para se destacar nele. O mesmo acontece com a programação. Todos nós conhecemos a receita, mas muito poucos realmente arregaçaram as mangas, sujaram as mãos e praticaram o tempo necessário para dominar esse ofício.

Portanto, mesmo quando um programador médio é comissionado em um projeto, ele sem saber escreveria código com dívida de tecnologia incorporada a ele, o que ele não perceberia até mais tarde. E se você está se perguntando como a indústria está funcionando positivamente em geral com a maioria dos programadores sendo impróprios para o trabalho, é por causa de seus gerentes eficientes e seus veteranos experientes que aprenderam as coisas da maneira mais difícil. Eles ajudam essas mãos e mentes frescas a navegar pelos caminhos traiçoeiros de escrever o código ideal e tornar o envio do projeto viável e mantê-lo livre de uma dívida pesada. E, eventualmente, com preparação e treinamento adequados, esses novatos para se tornarem bons em seu trabalho, ou eles acabam dando adeus à indústria de TI.

Então, em conclusão, sinto que todas as 3 principais partes nesta colaboração devem compartilhar a culpa pela compilação da dívida de código. Mais uma vez, não tome esta peça como uma peça desmontável para tudo o que há de errado com a indústria. É como qualquer outra indústria do mundo, com seu quinhão de horrores e heróis. Mesmo depois de 10 anos fazendo isso, eu ainda não faria mais nada com a minha vida. Adoro este trabalho, adoro ser uma pequena empresa trabalhando em projetos interessantes de clientes em todo o mundo.

O objetivo era tornar todas as 3 partes interessadas mais responsáveis ​​e familiarizá-las com essa perda leve subjacente que estava sendo atingida por uma colaboração incorreta. Se uma equipe de desenvolvimento de software deseja calcular e medir com precisão sua dívida tecnológica, ela pode seguir um modelo de processo rigoroso baseado na metodologia Agile, ou mesmo na metodologia Waterfall. Ao seguir essa abordagem disciplinada, você poderá marcar esses sprints de revisão e reparo separadamente e, no final de uma fase, poderá calcular com precisão quantos deles você precisou e chegar facilmente ao razão para isso.

Vou terminar com esta citação conclusiva de Samuel Beckett: