Codar é, sem dúvida, uma das etapas menos importantes quando olhamos para a engenharia de software como um todo. A analogia que sempre repito é bastante esclarecedora: se compararmos a engenharia de software com a engenharia civil, codar é como o trabalho de um pedreiro. É uma fase vital, mas apenas uma das muitas necessárias para construir um projeto robusto e de sucesso.

Durante o desenvolvimento de qualquer projeto de engenharia complexo, seja ele um software, uma ponte ou um avião, produzimos uma infinidade de documentos que são a essência do projeto. Eles são a representação detalhada de cada aspecto, cada parafuso, cada linha de código. Eles permitem que centenas ou até milhares de profissionais trabalhem juntos, em harmonia, para fazer algo grandioso.

No engenharia de um software, por exemplo produzimos uma série de artefatos, especificação de requisitos, descrição do design, diagramas UML, planos de verificação. Entre outros. Esses documentos, são por definição parte do software. E eu diria que a qualidade do software depende muito mais destes artefatos do que do código propriamente dito.

O código é, na verdade, apenas uma "materialização" de todos estes documentos. Assim como uma ponte é apenas a materialização de diversos documentos de engenharia, desenhos técnicos, planinhas de cálculos, etc. Você já ouviu falar de uma ponte ou prédio que caiu por erro de construção? Não? Porque é virtualmente sempre por erro de projeto.

No software, é um pouco diferente, mas existem evidências científicas robustas que mostram que a maior parte dos bugs e defeitos pode ser rastreada para problemas de requisitos e design.

Assim essas etapas "preparatórias" são, em muitos aspectos, muito mais cruciais para o sucesso de um projeto que o próprio código. "Preparatórias" entre aspas, porque no universo do software, iteração e prototição com código funcional são fundamentais, então a construção deste artefatos deve acontecer de forma quase paralela ao código.

Por que alguns devs se incomodam tanto com especialidades como DBA, UX/UI, Gerente, Arquiteto, QA, PM e PO etc? A resposta pode estar na comparação com a construção civil. Esses devs são semelhantes aos mestres de obras que constroem casas: em projetos simples que já têm experiência, talvez eles realmente não tenham a necessidade de todos esses profissionais especializados. Eles podem ter habilidades suficientes e gerenciar todas as etapas do processo por conta própria.

No entanto, assim como na construção, para qualquer projeto de maior complexidade, a ausência desses especialistas vai resultar em erros, atrasos e problemas de qualidade. Assim como um mestre de obras pode erguer uma casa sem a orientação de um arquiteto ou engenheiro, um desenvolvedor pode criar uma aplicação básica sem a ajuda de um DBA ou designer UX/UI.

Da mesma forma, estruturas mais complexas, como arranha-céus ou pontes, exigem uma equipe diversificada de especialistas, softwares mais robustos e complexos também demandam uma variedade de competências para assegurar sua eficácia e qualidade. A resistência a essas especialidades é fruto de uma falta de compreensão da importância e do valor que cada uma delas adiciona ao processo de desenvolvimento, normalmente devido a falta de exposição à projetos de maior complexidade.