A década de Uh-Oh do desenvolvimento de software corporativo

Codonomics Blocked Unblock Seguir Seguindo 23 de dezembro A era dos gerentes de projetos (certificado PMP)

Esta foi uma década em que não era fácil para uma start-up dar à luz, pois as coisas eram tão complexas e caras também. Não houve promulgação de ferramentas e tecnologias de código aberto e a nuvem barata que tira muito da dor de você para gerenciamento de infraestrutura simplesmente não estava lá.

Essa era uma época em que uma empresa era dolorosamente dependente de outra para os serviços especializados que a outra fornece. Isso exigia a necessidade de gerentes de projeto sobre gerentes de engenharia. E a piada viral na comunidade era algo como:

“Se você tem uma pessoa na equipe de desenvolvimento que não é capaz de nenhuma de suas funções, mas está sobrevivendo por sua conversa fiada, faça dele um Gerente de Projeto”.

A equipe de desenvolvimento costumava odiar a gerência por isso. Mas qual foi o ponto de vista da administração? Para eles, eles viram uma oportunidade na escuridão, em que queriam alguém que, embora fosse insincero em seu trabalho, pudesse prosperar em ineficiências e esperançosamente ser leais à empresa na identificação das ineficiências dos prestadores de serviços terceirizados dos quais dependem. para reduzir o custo de suas dependências. As empresas estavam tão concentradas no custo operacional de dependência do que na eficiência e qualidade de entrega do produto de software que estava sendo implantado.

Muito cedo tive a sorte de ter aprendido tudo isso em virtude das oportunidades que tive no meu prato e a curiosidade irrefreável de aprender mais. A partir desse mundo caótico, passamos para um diferente mundo caótico de desenvolvimento de software. Este post, no entanto, é para contar a história em breve sobre o caos no desenvolvimento de software corporativo na época.

Tempos em que as equipes de desenvolvimento não usavam cortadores de unha ..

Minha história de desenvolvimento de software empresarial do desenvolvimento à implantação nessa era

  • O desenvolvimento local no RAD-IDE (Rational Application Development IDE) da IBM, que veio com o IBM WebLogic Server integrado, costumava ser tão rápido que, a cada implementação de mudanças de código, o servidor forçaria você a sair do seu lugar e optar por um passeio / água / café / apenas um intervalo / do-multi-tasking. Não é de se admirar que a multitarefa tenha sido um exagero naquela época.
  • Como o servidor WebLogic local consumia a maioria de seus recursos locais (memória, processador, etc.), normalmente, os desenvolvedores costumavam ter seu banco de dados de desenvolvimento em um ambiente de servidor local separado. Em alguns casos, isso ficou ainda mais complicado quando todos os desenvolvedores estavam literalmente compartilhando a mesma instância de banco de dados remota. As equipes costumavam implorar literalmente por uma instância de banco de dados separada por desenvolvedor. Formas outrora improdutivas de construir software foi como definimos, brincando, o “Desenvolvimento de Software Empresarial” entre o nosso grupo de desenvolvedores.
  • E se você acha que foi tudo o que havia para este circo? Certamente havia mais. O clímax é sempre a fase de liberação. A equipe de desenvolvimento cria o arquivo WAR / EAR de grande importância e o entrega à equipe de operações.
  • A equipe de operações assume o artefato e o implementa no IBM WebLogic Server. Essa situação ficou ainda mais complicada quando a equipe e a implementação do Ops foram feitas no ambiente de servidor IBM pelo pessoal da IBM. Por quê? Porque você tinha que planejar cada release seu, levantar uma solicitação de suporte com a IBM, acompanhar as aprovações, enviar artefatos e esperar até que a implementação fosse concluída e receber a notificação da equipe do IBM Ops.
  • A situação piora e se torna um pesadelo, se por algum motivo você tiver apresentado um artefato errado ou houver erros críticos na aplicação. Graças aos Gerentes de Projeto da IBM que elaboraram o contrato com sua empresa, você não teve escolha a não ser levantar uma solicitação urgente de implantação de alto custo. Os tíquetes de implantação urgente normalmente custariam à empresa o dobro do preço do tíquete de suporte comum. Mas como isso afetou o desenvolvedor? Como se a crise de implementação não fosse suficiente, o Gerente de Projeto arrastaria o desenvolvedor pobre para uma sala de reunião para fazer RCA (Root-Cause-Analysis). Porra, tal era a vida estressante de um desenvolvedor.

Boa viagem para aquela época!

Ou você ainda está nessa época, até hoje?

  • Se você pertence à equipe de desenvolvimento, deve procurar mudanças.
  • Se você pertence à alta administração, deve procurar ajuda de especialistas.

De qualquer maneira, é hora de você abraçar a nova era do caos. Abrace a mudança e prepare-se para um futuro melhor em 2019!

Este post também é publicado nos meus outros canais de blogs – Codonomics e LinkedIn .