Tenho uma ideia errada sobre engenharia de software? [fechadas]

Tenho uma pergunta que foi levantada pelo meu último emprego (um pouco estagiário).

Apenas para colocar as coisas em contexto - tenho 21 anos e terminei meu segundo ano de universidade antes disso, tive cerca de 2 anos de experiência em trabalhos de administração de sistemas / controle de qualidade e, basicamente, posso dizer que vi como diferentes Setores de TI operados. Avancemos para os tempos atuais e aqui estou eu conseguindo um emprego em uma das principais instituições de pesquisa do Reino Unido.

O que preciso fazer é criar algumas ferramentas internas usando uma combinação de tecnologias - principalmente AWS / Java / Bash - para você entender. Está tudo bem, estou fazendo o meu trabalho, mas não estou feliz. Por que isso - porque eu devo trabalhar em um assunto ad-hoc. Isso é criar coisas rapidamente, sem gastar tempo em projetar. Meu gerente disse explicitamente que era esperado que "apressasse" os problemas à medida que eles surgissem e nós essencialmente. Como conseqüência, verificou-se que as coisas tinham que ser refeitas e reprojetadas e ainda não são perfeitas. No que diz respeito ao teste - mantenha-o no mínimo, desde que pareça funcionar, então tudo bem.

Tenho a culpa de discordar dessa maneira de conduzir o trabalho? É errado querer pensar sobre o sistema como um todo, depois focar em diferentes componentes e ver como eles podem interagir, para se concentrar em diferentes "pontos-chave" que podem vir a ser problemáticos no futuro? É um crime querer fazer um bom trabalho e não um "trabalho rápido"? É um erro ou atitude errada querer pesquisar as estruturas de dados aplicáveis ​​a um problema, para que você possa escolher o melhor, dependendo de um conjunto de problemas específico? Até onde eu entendi, o trecho "Engenharia" em "Engenharia de software" tem a ver exatamente com isso - pesquise o domínio do problema e encontre uma solução informada e refine conforme necessário?

Eu estive em uma entrevista em um escritório da Arm no Reino Unido e eles me mostraram a sala do SCRUM e parecia que eles tinham uma boa idéia de como gerenciar seu projeto - eles tinham uma carteira de pedidos, tinham métricas sobre quanto tempo cada um problema pode ser resolvido - as coisas usuais para o SCRUM - completamente diferentes da maneira como as coisas são executadas "aqui"

Criei uma ideia errada sobre a indústria de software em geral? Eu gostaria de ouvir sua opinião sobre isso. Quero dizer, eu "entrei" no desenvolvimento de software apenas porque quero criar coisas - claras e simples, mas quero criar coisas de qualidade. Quero ver meu software usado em vários cenários, quero vê-lo à prova de balas - essa não é a força motriz para todos os engenheiros de software? Eu acho que todo mundo pode ser um programador / programador apenas aprendendo a sintaxe, mas para mim, onde a verdadeira diversão começa é quando você precisa criar um design que seja possível no mundo real.

Eu costumava fazer minhas tarefas na universidade apenas olhando para elas e iniciando a codificação diretamente, conseguindo facilmente notas acima de 75% e nunca realmente apreciei o módulo "ciclo de vida de desenvolvimento de software". Mas agora, quando vi no mundo real como é ruim trabalhar sem nenhum processo formal e a frustração inerente à situação em que você não sabe se os requisitos mudarão amanhã (oh, eu disse que não possui análise de requisitos claramente definida?)

Eu realmente gosto de acreditar que acabei de chegar a uma posição em que algumas pessoas apenas precisavam de um macaco de código para fazer seu trabalho sujo, e esse não é o caso de como o mundo do software opera em geral.

Tornar o software reutilizável e à prova de balas não é a força motriz da engenharia de software. Engenharia é resolver problemas do mundo real de maneira ideal dentro das restrições do mundo real . A maioria dos engenheiros prefere trabalhar em uma Ferrari - mas uma perua precisa da mesma engenharia, e a razão pela qual uma perua não funciona tão bem (em alguns aspectos) é devido a restrições de projeto mais difíceis, não a uma engenharia pior .

Quando você diz que deseja fazer um "bom trabalho" em vez de um "trabalho rápido", a maioria dos engenheiros faz, mas às vezes parte do que define bom é a rapidez com que é concluída. Portanto, não é correto pensar em "bom" e "rápido" como opções opostas. Ou pensar que você está fazendo um mau trabalho, ou é apenas um "macaco de código", por fazer o melhor trabalho possível no tempo disponível.

Obviamente, é bem possível que o processo não seja o ideal e faça melhor com um pouco mais de design antecipadamente. O teste de ácido seria: a maneira atual de fazer as coisas está criando mais problemas do que soluciona para os usuários ou está apenas incomodando os desenvolvedores que precisam trabalhar dessa maneira? Se realmente está causando problemas para os usuários, parte do seu trabalho é tentar demonstrar que é esse o caso e tentar convencer as pessoas a um processo um pouco mais controlado.

Na verdade, isso me incomoda. Você está em uma profissão onde desenvolve ferramentas para cientistas, correto. No entanto, você deve acelerar esses programas e fazer com que eles pareçam funcionar minimamente. Surpresa surpresa. Esta é simplesmente a abordagem típica do pesquisador em programar com o dinheiro passado para um programador real.

A principal preocupação aqui é que a falta de testes em particular pode ser eticamente duvidosa se as ferramentas tiverem um objetivo importante. Se não se tem certeza de que o software possui defeitos, porque se restringe a um tempo mínimo de teste, isso significa que NINGUÉM é responsabilizado pelas condições de trabalho do software, e a Atlas encolhe os ombros.

Vamos parar e pensar sobre isso por um segundo. Que tipo de ferramentas você está desenvolvendo? Se você está desenvolvendo software que modela dados, há um grande dilema ético aqui. Em algumas situações, a pesquisa científica leva a decisões que afetam muitas pessoas em grande escala.

Suponha, por um instante, o controverso tópico das mudanças climáticas provocadas pelo homem. Digamos que eles colocaram os mesmos padrões no software de modelagem que eles usam para chegar às conclusões que eles têm hoje. O tópico tem um grande impacto em como abordamos o gerenciamento correto do meio ambiente e a política internacional.

Não é ético garantir que o software de modelagem não tenha grandes problemas com suas previsões?

O problema não é que os gases de efeito estufa aqueçam a terra. O problema é se o resultado líquido dos efeitos de realimentação é um ganho acelerado de temperatura, que após quebrar um limite não seria mais reversível.

Se esse ganho estivesse ocorrendo, a evidência de um resultado líquido seria marginal, provavelmente dentro da faixa de erro.

Portanto, pequenos erros de cálculo, mesmo a metodologia que envolve armazenamento e recuperação de dados no back-end, podem resultar em ignorar um sério problema ambiental em uma das extremidades da falha ou em uma política internacional que afeta muitas pessoas (destrói empregos, destrói aposentadorias etc.) ) no outro.

Então, sim, você está certo. Não me interessa qual é o ritmo da pesquisa ... Se os pesquisadores querem contar com ferramentas de software para gerenciar dados e realizar cálculos para eles, precisam aprender a esperar pelo software correto. Caso contrário, esse software se tornará um ponto de vulnerabilidade em suas teorias pelas quais eles não são responsabilizados, resultando em má conduta ética.

Você não tem a idéia errada sobre o que é engenharia de software. No entanto, você está perdendo um aspecto muito importante: este é um setor de serviços. Alguns de nós começam a trabalhar em um produto há anos e passam pelo design e, em seguida, por muitas iterações antes da versão v1. Outros têm que produzir algo em 3 horas. Depende de quem você está atendendo e qual é o objetivo.

Se você pode produzir um aplicativo em 3 horas (ou dias) que faz o que ele deve fazer, por que gastar mais tempo nele para projetar com antecedência? Você está apenas desperdiçando dinheiro. Desperdiçar dinheiro geralmente não é uma boa idéia ™.

Como outros já disseram, grande parte do que é a engenharia de software são "restrições extrínsecas". por exemplo. Tempo, orçamento, serviço, suporte, satisfação de demandas idiotas irracionais, etc.

Muitos de nós (inclusive eu) entramos em programação pensando que é tudo sobre a programação em si - codificando peças de software bonitas e elegantes no vácuo (ou no mínimo um vácuo relativo). Isso raramente é. Pode haver alguns trabalhos acadêmicos ou de P&D raros em software que se aproximam, mas, na maioria das vezes, a esmagadora maioria do trabalho de desenvolvimento de software não é nada disso. Especialmente na fase de manutenção - que normalmente é mais de 90% da vida útil de um produto - e na rotina diária do pão com manteiga da maioria dos trabalhos permanentes de software comercial.

Por um longo tempo, tive um conflito interno sobre isso que muitas vezes me deixou infeliz com o meu trabalho (e é parte do que acabou levando a um esgotamento no ano passado). Sempre achei que um trabalho é péssimo se não se trata de criar um código bonito e de dedicar algum tempo para fazê-lo adequadamente. Mas, na verdade, essa é a realidade - e algumas pessoas realmente prosperam com um fluxo de trabalho muito orientado a serviços. É o que os faz sentir pragmáticos e úteis. Mesmo que os aspectos reais de "engenharia de software" de um projeto sejam relativamente apressados ​​e desleixados.

De qualquer forma, é bom que você esteja questionando isso agora. Essa é uma daquelas coisas que eles nunca explicam adequadamente na escola. E as empresas gostam de fingir que seguem boas práticas de engenharia, mesmo que não sigam. Dica: a maioria não.

Tudo isso dito, as coisas variam. Certas empresas (principalmente aquelas para quem o software é seu negócio principal e aquelas que trabalham em softwares altamente críticos para a segurança, como equipamentos médicos) seguem um processo de engenharia muito rigoroso. Mas no geral, sim, vou lhe dizer agora que a maioria dos softwares comerciais é relativamente desleixada. Geralmente, existe algum processo formal, mas a adesão estrita a ele quase sempre leva a uma contrariedade às reações dos clientes e outras pressões comerciais. Não é realmente "negligência" por si só, é apenas uma utilidade pragmática. O truque é encontrar seu nicho e analisar uma função do ponto de vista de qual serviço ele presta, em vez de quão legal é o aspecto de "programação pura".

Edição : Eu acho que poderia ter soado muito unilateral na minha avaliação inicial. Eu gostaria de acrescentar que, muitas vezes, também existem problemas genuínos com coisas muito desleixadas e falta de bom processo - a ponto de levar o projeto a dívidas técnicas e, na verdade, é ruim para os negócios. Mas ver isso vem com a experiência. O ponto inicial ainda permanece basicamente: a maioria dos softwares comerciais hoje em dia não é tão rigidamente orientada para a engenharia quanto os puristas gostariam.

Que pergunta excelente! Às vezes, você pode fazer algo valioso sendo rápido . Esse é geralmente o caso em um laboratório de pesquisa em que quanto mais rápido aprendermos o que não sabemos, melhor estaremos. O software que você produz existe apenas para responder a perguntas. É "jogar fora o código". Este também é o caso de startups que não sabem o que os clientes realmente querem. Além disso, a primeira vez que você fizer algo, será ruim. Leia O Mito do Homem-Mês .

Às vezes, você pode fazer algo valioso sendo bom . Normalmente, esse é o caso de softwares encolhidos como o Adobe Photoshop. A pesquisa já foi feita anos atrás e agora a questão é como adicionar a lista de recursos que os clientes desejam de uma maneira que não introduza bugs. É uma questão de arquitetura, design e teste, teste, teste. O código em si é o que é valioso, não o que você aprende com ele.

Se você não está satisfeito com a pesquisa (criando o primeiro de algo, aprendendo coisas novas que ninguém sabia antes), experimente o software compacto. De fato, na sua idade, você deve tentar o máximo de coisas possível. Vá correr riscos! Você aprenderá muito e estará melhor no longo prazo.

Acho que você percebeu muito cedo em sua carreira que fazer as coisas rapidamente, sem um design ou teste adequados, tende a voltar a mordê-lo. Você obviamente não gosta disso e tem boas razões para não gostar. É ridículo esperar que "apresse os problemas", especialmente se você precisar revisá-los mais tarde, quando as soluções iniciais estiverem incorretas ou incompletas. Você só pode fornecer soluções para os problemas se entendê-los completamente, e isso leva tempo e planejamento cuidadoso.

Minha sugestão para você é que seus superiores saibam que isso a incomoda e sugira a eles uma melhor abordagem para realizar seu trabalho. Se eles não concordam e querem que você continue "apressando-se" no seu trabalho, eu começaria a procurar trabalho em outro lugar. Não faz sentido fazer as coisas de maneira que não atenda aos seus próprios padrões, muito menos um padrão de qualidade de desenvolvimento de software que a indústria espera.

Aqui está o meu conselho com base em minhas experiências, tenho 20 anos e atualmente trabalho para uma grande instituição financeira no Reino Unido e tinha os mesmos sentimentos que você tinha há alguns meses, o que eu notei é que isso talvez se deva à natureza de o trabalho que você está fazendo.

O que quero dizer com isso é que você disse:

“O que preciso fazer é criar algumas ferramentas internas usando uma combinação de tecnologias - principalmente AWS / Java / Bash”

Eu também tive que criar ferramentas internas para ajudar a gerenciar e automatizar certos processos, e o fato é que, em um ambiente de ritmo acelerado, “pequenas” coisas precisam ser implementadas rapidamente. Eu não tive o luxo de aplicar a maioria dos princípios de engenharia de software ou algoritmos e estrutura de dados que aprendi no meu segundo ano porque uma versão de trabalho da ferramenta era necessária em poucas semanas. Fiquei muito frustrada com isso. não é tão ruim quanto aprendi a escrever um código melhor e mais legível.

Eu tinha que ser paciente e recentemente mudei para uma nova equipe que está trabalhando em uma nova iteração de sistema interno usado por usuários de mais de 10 mil e posso garantir que o aspecto de engenharia de software é levado muito a sério. Foi-me dito que ficarei exposto ao ciclo de vida completo do software, desde a captura / análise de requisitos até a implementação e teste. Acredito que vou ganhar essa experiência porque não estou trabalhando em ferramentas internas, mas trabalhando em um sistema de grande escala com uma grande base de usuários.

O que eu recomendo é que você seja paciente, termine de criar as ferramentas e faça um ótimo trabalho para que seus supervisores adquiram mais confiança em você e atribua tarefas mais desafiadoras que exigirão o uso dos princípios de engenharia de software. Adquira conhecimento extra ao ler um pouco mais e aplique esse conhecimento ao que você está fazendo no momento. Lembro-me de ter saqueado toda a biblioteca de e-books da empresa apenas para aprimorar meu conhecimento muhahah, de todos os livros que li, senti que o Java eficaz era livro realmente bom que me ajudou muito.

Apenas seja paciente, invista fortemente em seu próprio conhecimento e aplique esse conhecimento sempre que possível. Se você estiver fazendo um bom trabalho, alguém logo notará.

Concordo que o modo como o seu trabalho atual é subótimo, sim. No entanto, se você quiser dizer que não funciona, eu discordo de você, pois há vários resultados e a instituição ainda está por aí.

Minha principal pergunta é: até que ponto você está lidando com incêndios que exigem soluções imediatas feitas rapidamente, de maneira semelhante a dar primeiros socorros a um paciente médico versus solicitações que podem ser configuradas como projetos e tratadas em uma escala muito diferente do paciente médico ter que agendar testes e vários procedimentos que não são necessários imediatamente, mas no curto prazo.

Reservar um tempo para fazer um trabalho bem depende um pouco da maturidade da organização, além de quão importante é que algo seja bem feito versus uma alegação de que está sendo feito.

A questão de pesquisar as estruturas de dados é quanto tempo está querendo fazer isso. Se você quiser levar uma década para pesquisar uma estrutura de dados, é bem diferente de querer duas horas. Embora eu aprecie o desejo de obter a melhor resposta, há algo a ser dito para diminuir os retornos após dedicar algum tempo a um problema; por exemplo, você poderia passar horas encontrando uma solução para o FizzBuzz e tentar resolvê-lo em vários idiomas no vários hardwares para otimizar o quão rápido ele pode ser executado.

Embora possa ser importante pesquisar, também é importante fornecer algo. Se você não entrega algo, como você é realmente bom? Programador de fita adesiva seria mais um exemplo de como fazer as coisas aqui.

Scrum é uma metodologia específica que você poderia tentar adotar no seu local de trabalho atual. Não pense que Scrum é uma bala de prata. Em que circunstâncias os projetos sob Scrum e o Agile falham? seria uma postagem de blog sobre esse assunto que possa ser de seu interesse.

Meu palpite é que você não está vendo como os processos de seu local atual são informais e pensando que a grama é imensamente mais verde do outro lado, onde existe uma metodologia formal. Embora possa ser melhor lá, algumas pessoas podem preferir o que você tem agora com a enorme liberdade de ser um cowboy .

Eu acho que sua situação ainda está na escala do mundo real, com menos ênfase no lado da qualidade. Sua preferência é do outro lado do mundo real. As especificações mudam, supere isso. As coisas precisam ser feitas.

Considere maneiras de identificar esses tipos de empresas quando se candidatar ao próximo emprego. Poucos lugares têm um modelo de negócios em que podem se permitir que os desenvolvedores analisem seus projetos para sempre (até os professores precisam ensinar). Os clientes raramente pagam se o seu trabalho não sai do papel. Odeio ver você enlouquecer tão cedo em sua carreira.