Por que a indústria de TI não consegue entregar projetos grandes e sem falhas, como em outras indústrias?

Março de Morte de Ed Yourdon toca um número dessas perguntas do tipo meta.

Em geral, a indústria de software não possui muitos dos seguintes itens, o que atrapalha grandes projetos.

• Padronização e detalhamento do item de trabalho.

  • Isso certamente melhorou, mas as construções de design ainda não estão lá para criar um grande sistema. De certa forma, o software nem chega a um acordo sobre o que é necessário para um determinado projeto, muito menos a capacidade de dividir as coisas em componentes.
  • Aeroespacial, construção de edifícios, automóveis, etc. todos têm arquiteturas muito orientadas a componentes com interfaces razoavelmente justas para permitir um desenvolvimento totalmente paralelo. O software ainda permite que haja muita perda nas áreas correspondentes.

• Uma grande quantidade de projetos semelhantes e bem-sucedidos. O A380 não foi o primeiro grande avião que Airbus construiu. Há muitos aplicativos de software grandes por aí, mas muitos deles sofreram dramaticamente em algum aspecto ou outro e não chegaram perto de serem chamados de "bem-sucedidos".

• Um grande grupo de designers e construtores que trabalharam em vários projetos semelhantes e bem-sucedidos. Relacionado com a questão do projeto de sucesso, não ter o talento humano que esteve lá, o que torna as coisas muito difíceis do ponto de vista da repetibilidade.

• "Nunca" construindo a mesma coisa duas vezes. De muitas maneiras, um avião é como qualquer outro avião. Tem asas, motores, assentos, etc. Os grandes projetos de software raramente se repetem. Cada kernel do SO é significativamente diferente. Veja a disparidade nos sistemas de arquivos. E, nesse caso, quantos SOs verdadeiramente únicos existem? Os grandes tornam-se clones de um item básico em algum momento. AIX , Solaris , HP-UX , ... o arauto de volta para AT&T System V . O Windows teve uma quantidade incrível de avanço em cada iteração. As variantes do Linux geralmente retornam ao mesmo núcleo que o Linus iniciou. Eu levanto, porque as variantes tendem a se propagar mais rápido do que os OSs verdadeiramente exclusivos e proprietários.

• Estimativa de projeto muito ruim. Como o fator de repetibilidade é tão baixo, é difícil projetar o tamanho que ele vai ter e quanto tempo levará para construir. Dado que os gerentes de projeto e a Gerência não podem colocar as mãos no código e realmente ver o que está sendo feito, expectativas irreais em relação aos cronogramas são geradas.

• O QA / QC não é enfatizado tanto quanto poderia ou deveria ser para projetos maiores. Isso remete a interfaces mais flexíveis entre os componentes e a não ter especificações rígidas de como os componentes devem funcionar. Essa frouxidão permite conseqüências não intencionais e erros se infiltram.

• Qualificações consistentemente mensuráveis. Geralmente, as pessoas falam do número de anos em que trabalharam na linguagem X ou na programação. O tempo em está sendo usado como um substituto para o calibre ou a qualidade da habilidade. Como já foi mencionado muitas vezes, entrevistar e encontrar bons talentos de programação é difícil. Parte do problema é que a definição de "bom" permanece muito subjetiva.

Não pretendo ser negativo, e acho que a indústria de software fez avanços significativos de onde estivemos. Fóruns como este e outros realmente ajudaram a promover conversas e discussões sobre princípios de design. Existem organizações que trabalham para padronizar o conhecimento de "linha de base" para engenheiros de software. Certamente há espaço para melhorias, mas acho que a indústria percorreu um longo caminho em um período razoavelmente curto de tempo.

A resposta é surpreendentemente simples: essas 'outras indústrias' do têm uma alta taxa de falhas. Estamos apenas comparando as coisas erradas. O software de escrita é frequentemente chamado de 'compilação' e, portanto, comparamos com as fases de fabricação ou construção em outras indústrias. Mas se você olhar para isso, não é construção: é design . Os projetos de software são escritos em código e a construção é feita por computadores, seja compilando softwares ou diretamente interpretando-os em tempo real.

Muitos projetos em outras indústrias levam mais tempo do que o estimado originalmente, custam muito mais ou simplesmente nunca são concluídos. Soa familiar?

Então, o que estamos fazendo quando estamos planejando software? Bem, ainda estamos projetando, mas em um estágio anterior.

No software, não há linha de produção de nota. Construir o componente final é (comparativamente) barato, e a replicação desse produto final é perfeita e efetivamente livre - você copia os artefatos de construção.

Para apontar alguns números:

1. Alteração de requisitos após o início da implementação ; por exemplo, quando o primeiro Airbus A380 começou a ser criado na fábrica, não posso acreditar que, se alguém quisesse mais 200 assentos, eles seriam colocados lá; mas em um grande projeto de software, mesmo depois que os programadores começaram o desenvolvimento, mais 5 tipos de usuários podem ser adicionados.
2. Complexidade - grandes projetos de software são extremamente complexos; provavelmente os projetos mais complexos tipo humano projetados e desenvolvidos;
3. Não são gastos recursos suficientes na arquitetura e na fase de design ;
4. Imaturidade do campo - a engenharia de software é relativamente uma disciplina jovem comparada com outras irmãs de engenharia; isso tem duas implicações: a) Não tantas heurísticas e boas práticas; b) Não tantos especialistas muito experientes;
5. Falta de prova matemática - na maioria dos casos, os métodos formais matemáticos não são usados para provar que um software funciona como requerido; em vez disso, o teste é usado. Isso é verdade em outros campos de engenharia que dependem mais da matemática; a razão disso é como complexidade;
6. Rush - muitos gerentes têm prazos inatingíveis; então a qualidade do código é colocada em segundo lugar, devido ao prazo final.

Respondendo estritamente à pergunta - Eu costumo acreditar que os outros têm expectativas muito altas (especialmente no tempo de entrega) dos programadores e não entendem exatamente quão difícil é o software de programação grande.

A premissa da questão é um pouco falha. Tanto o A380 quanto o Boeing 787 foram entregues anos atrasados.

No caso do A380, grande parte do atraso foi causado pelas unidades francesas e alemãs da Airbus, usando versões diferentes e ligeiramente incompatíveis do software de design CATIA . Isso se manifestou de forma incompatível como chicotes de fiação que não se ajustavam ao avião.

Não havia nada de errado com o CATIA, que é o software de design de aeronaves mais usado, mas alguém em algum lugar deixou cair a bola de configuração de software.

Grandes projetos complexos são difíceis para os humanos em todos os campos.

Tipo de arranha-céu aqui. Não tenho certeza se posso responder a sua pergunta, mas posso certamente lançar alguma luz em vários itens do tópico. Os edifícios de fato ocorrem muito rapidamente. Uma restrição importante é o local (regulamentos). Mas, em geral, leva de 3 a 10 anos para um prédio alto do começo ao fim.

Acho que comparar um novo prédio com um novo projeto de software não é muito preciso. Um novo edifício está mais próximo de uma nova versão de um kernel ou sistema operacional. Nesse aspecto, o desenvolvimento de software é muito mais rápido. Nós nunca construímos a partir do zero, pois esta será uma tarefa de alto risco que o cliente nunca iria se inscrever. A maioria dos projetos e desenvolvimentos em edifícios é derivada de projetos comprovados e concluídos.

Da experiência pessoal, apenas um em cada dez projetos é construído. O processo é impulsionado pelo desenvolvimento e não pelo design, então no momento em que algo como o preço do aço sobe, todo o projeto está fora da janela, ou projetado, já que o design é o componente barato do processo.

O projeto leva um mês para o conceito esquemático, dois a seis meses para o desenvolvimento do projeto, outros seis meses para detalhes e documentos de construção por uma equipe de arquitetos, consultores de planejamento, engenheiros de engenharia, engenheiros de serviços, consultores de quantidade e custo , agrimensores, engenheiros de acessibilidade e a lista continua ...

O argumento virtual versus físico não é muito preciso. Também trabalhamos principalmente com ferramentas virtuais e, além disso, estamos em tempo e escala remotos em relação ao nosso produto final. Na maioria dos casos, não podemos sequer testar aspectos de edifícios em escala de simulação e usamos a simulação para tentar prever o que pode acontecer.

Existem diferenças em termos de complexidade, mas no geral é praticamente o mesmo. Nós não apenas temos unidades inter-relacionadas e múltiplos níveis de abstrações e interfaces em camadas, mas também pessoas muito especializadas em pequenas partes do processo que tornam a comunicação muito difícil.

Quanto ao argumento do design versus desenvolvimento, acho que ambos os processos são construídos com design. Parece academicamente legal mantê-los separados, mas não é possível projetar se você não sabe como as coisas funcionam. Você apenas aumenta o risco de falha.

Um aspecto que me impressiona em design e desenvolvimento de software é o próprio meio. Os computadores tornam o trabalho centrado no ser humano muito antinatural. Tudo é muito explícito e existem poucas tolerâncias. É difícil trabalhar mentalmente com isso, e alguns conseguem se livrar dessa complexidade. Se nada mais isso pode ter algo a ver com isso?

Então, quanto tempo demorou o design deles? Ano? Dois? Dez anos? O design é a parte mais complexa da construção de algo, a própria construção é fácil.

Com base em este artigo , está sendo lentamente compreendido que o desenvolvimento de software é principalmente o processo de design, onde o documento de design é o próprio código-fonte. E o processo de design é totalmente diferente do processo de produção. Requer pessoas experientes e é impossível planejar, porque mesmo pequenas mudanças nos requisitos podem resultar em grandes mudanças na arquitetura geral do projeto. Esse entendimento é a base para metodologias ágeis que enfocam a melhoria da qualidade do código como o documento de design final e a realização de testes e depuração como partes do processo de design, assim como eles testam modelos de avião em túneis de vento.

A construção em si é tratada automaticamente por compiladores. E graças a isso, somos capazes de construir produtos inteiros em questão de minutos.

A razão pela qual os projetos de software são concluídos com enormes atrasos e custos inflacionados é porque os gerentes ainda acham que podem estimar, prever e planejar esse processo de design. Isso sai pela culatra com mais frequência do que é realmente válido. Eles ainda acham que, ao amarrar as pessoas em um processo de construção rígido, elas podem, de alguma forma, aumentar a qualidade, mesmo que o resultado final seja o oposto, com aumento de custos e prazos perdidos.

Imagine, no meio do projeto do Airbus A380, alguém se reuniu em uma reunião e disse: "Heh, poderia construí-lo como um triplano?" Outros se juntaram dizendo: "Sim, sim. Um triplano. Mais asas são melhores." Os próximos anos são gastos transformando o projeto do A380 em um triplano. Em outra reunião, alguém diz: "Um triplano? Isso é velho. Queremos um biplano. Basta remover uma das asas".

Ou imagine, no meio de um projeto de construção de ponte, alguém diz: "Heh, acabamos de fazer um acordo com uma empresa de navegação. Eles precisam que a ponte seja mais de 40 pés, porque seus navios são muito mais altos. Obrigado. "

Estas são apenas algumas das razões pelas quais os projetos de software, grandes e pequenos, terminam em falha em um ritmo alarmante.

Como alguém com experiência em engenharia mecânica trabalhando em TI, muitas vezes me perguntei sobre as razões da baixa taxa de sucesso em TI.

Como outros neste tópico, eu também atribuí muitas vezes as falhas à imaturidade da TI, a falta de padrões detalhados (sim, estou falando sério, você já verificou a folha padrão de um simples parafuso?) e o falta de componentes e módulos padronizados.

Outras indústrias, como a construção civil ou a construção naval, também têm muito mais "caminhos batidos": o conhecimento e a experiência de um determinado protótipo de solução, que - de forma personalizada - é reutilizado repetidas vezes. Já se perguntou por que edifícios, navios ou aviões de tamanho e propósito diferentes parecem tão parecidos? (há exceções à regra, é claro ...)

Isso porque esses protótipos são bem pesquisados, bem compreendidos, geralmente usados e têm um histórico comprovado. Não porque não pudesse ser feito de outra maneira. Na TI, a padronização raramente é o caso: projetos (grandes) tendem a reinventar componentes, fazendo pesquisas e entregas ao mesmo tempo e com as mesmas pessoas!

Dito isto, há fatores que tornam a TI verdadeiramente única, no entanto. Ao contrário das outras indústrias mencionadas, a TI é verdadeiramente onipresente: é usada em todos os aspectos da nossa vida moderna. Portanto, é um pequeno milagre que a TI tenha conseguido esse progresso e seja capaz de fornecer os resultados que faz.

Tenho medo de não concordar com a sua afirmação.

A Airbus e a Boeing são dois exemplos de empresas que constroem aviões. Quantas empresas que constroem aviões estão lá? Muito poucos, se você comparasse com quantas empresas criam software.

É igualmente fácil parafusar um projeto de avião para estragar um projeto de software. Se apenas a barreira de entrada fosse tão baixa no setor de construção de aeronaves quanto na indústria de software, você certamente verá muitos projetos de aeronaves com falhas.

Olhe para carros; Existem fabricantes de alta qualidade que constroem automóveis muito duráveis e altamente avançados (pense em Land Rover, Mercedes) e há aqueles que constroem carros que não duram um ano sem ter que consertá-los (pense em Kia ou Cherry). Este é um exemplo perfeito de uma indústria com barreira de entrada ligeiramente mais baixa, onde você começa a ter jogadores mais fracos.

Software não é diferente. Você tem muitos produtos com bugs, por outro lado, Windows, Office, Linux, Chrome ou Google Search são projetos de alta qualidade que foram entregues no prazo e tinham um nível de qualidade semelhante ao de uma aeronave.

O software também precisa disso. Se apenas as pessoas gastassem tanto tempo com diagnóstico e prevenção, quanto com o estado e a qualidade do software de auditoria, como acontece com produtos mecânicos / físicos, eu esperaria declarações bem menos como essas. Você lê os registros do seu aplicativo toda vez antes de iniciá-lo? Bem .. se fosse uma aeronave você teria que; -)

Blocos de construção digitais podem ser 1 ou 0. Não há intermediários.

Um projeto mecânico tem um nível de tolerância. Eu posso colocar um rebite menos do que perfeito em uma ponte e ele provavelmente não irá cair, no entanto, no código, mesmo que apenas uma vez a instância de colocar um 0 onde um 1 deve ser, pode falhar o programa inteiro.

Devido à natureza lógica e interativa da computação, qualquer alteração, mesmo que muito pequena, pode levar a uma falha drástica.

Eu sempre me perguntei a mesma coisa. Certamente sente (ocasionalmente) como nós somos um bando de amadores que não têm idéia do que estamos fazendo. Eu não gosto de explicações que colocam a culpa em gerentes ou outros fatores externos - nós, os desenvolvedores, devemos ser responsáveis pelo que criamos.

Acho que estamos em um negócio em que os erros são baratos . O software de correção é barato, comparado à reconstrução de um arranha-céu ou ao recall de todos os celulares vendidos.

Isso criou uma cultura na qual os bugs fazem parte do dia a dia . Eles são aceitos com um encolher de ombros. Embora alguns bugs provavelmente sejam inevitáveis, eles devem nosso dia a dia de trabalho ? Eu entendo completamente os gerentes que não sentem que o QA vale a pena, precisamente porque eles esperam erros de qualquer maneira. Eu não entendo programadores que não fazem todo o esforço para produzir código livre de erros, porque corrigir bugs é chato como o inferno.

Essencialmente, acredito que seja um problema cultural e espero que isso mude.

Padrões e práticas de engenharia são muito diferentes em TI (como uma indústria independente) do que em aeroespacial . Isso talvez seja mais facilmente compreendido considerando-se como os profissionais de TI reagem quando encontram documentos padrões para TI no setor aeroespacial . Por exemplo, os Padrões de Combate às Caças de Ataque Conjunto que percorreram a Internet nos últimos tempos.

Muitos expressam perplexidade ou resignação melancólica (gostaria que pudéssemos fazer isso); e muitos respondem com ridículo, alegando que não há maneira prática de entregar produtos de consumo dessa maneira. Isso pode até estar certo, dadas as expectativas, não dos consumidores, mas da administração. Há uma grande dose de desconfiança para codificadores que apenas codificam e codificam por algumas semanas, não demonstrando nada. Deus ajude o codificador que apenas projeta algo por duas semanas. Não é assim com aviões.

No software, as pessoas realmente esperam ter algo agora. Claro, o raciocínio vai demorar um pouco para tê-lo realmente sólido; mas não podemos ter alguma coisa complexa descrita em termos simples em uma semana? Aprende-se, também, que as coisas complexas descritas em termos honestos e complexos raramente excitam a imaginação; e assim muitos engenheiros acabam sendo cúmplices em um mundo imaginado de coisas realmente simples sendo colocadas juntas de formas criativas (em oposição a um mundo de coisas difíceis sendo realmente bem feitas).

Algumas coisas minhas:

1- Padrões e partes: Eles são planos fabricantes , não desenvolvedores. Eu não tenho certeza, mas meu palpite é que muitas peças são terceirizadas. Eles não constroem seus próprios eletrônicos / instrumentos, eles obtêm assentos de alguma empresa, os motores provavelmente são desenvolvidos em outros lugares, etc.

Projetos de software, por outro lado, quase sempre começam do zero com apenas alguns pequenos frameworks / helpers no lugar.

2- Hora de chegar ao mercado: o tempo não é uma questão crítica para os aviões. Aposto que o design do Airbus foi finalizado anos antes de terminar, e eles escolheram negligenciar quaisquer grandes avanços que pudessem acontecer naquele tempo. (Mesmo para os fabricantes de automóveis, por exemplo, a tecnologia de ponta que eles desenvolvem no momento chegará às ruas em 5 a 10 anos).

Para software você precisa ser muito ágil, se eu começar um grande projeto agora e levar três anos para desenvolvê-lo sem qualquer mudança, é bem provável que eu esteja confiando em uma tecnologia que não está mais disponível ou meu produto esteja completamente desatualizado. Isso, por sua vez, oferece muitos problemas.

3- Ciclo de liberação e versões. - Um avião precisa estar completamente terminado quando é "liberado". Não há versões beta estáveis, compilações noturnas ou similares. Além disso, uma vez feito, só pode ser modificado de forma pequena. Você não pode adicionar um nível adicional com 100 lugares a um Boeing existente, simplesmente não é possível.

O software, por outro lado, tem alterações incrementais que são geralmente apenas "compilações que funcionam", mas não necessariamente produtos acabados. Além disso, em TI não é incomum dizer "ei, vamos adicionar outro compartimento de bagagem ao nosso avião, que possui 50 toneladas adicionais".

Acho que a resposta é bem simples:

1) A construção e implementação física existem há tanto tempo quanto as pessoas - nós tivemos milhares de anos para desenvolver nossos métodos e técnicas para implementar projetos físicos. A 'construção' de software, que requer um conjunto de habilidades inteiramente novo e diferente, não tem mais de 50 anos - ainda não tivemos tempo suficiente para descobrir tudo.

2) Construção virtual é mais difícil - você tem que 'ver' coisas em sua mente que não têm nenhuma realidade física. Ela exige que você analise e abstraia muitas informações antes mesmo de saber como deve ser seu produto e os passos necessários para criá-lo. Não é assim quando se constrói uma ponte ou um prédio.

3) Muitas vezes é muito mais difícil encontrar a fonte de uma falha ou erro de software do que quando se faz engenharia física. Se uma viga se dobra, você vê onde está afivelando e vê os suportes que a seguram e falham, etc. Encontrar um defeito de software pode envolver o exame de uma grande quantidade de código e processos interativos - difícil, demorado e não vinculado à leis da física e matemática da maneira que as estruturas físicas são.

Vou tentar responder usando uma cópia fiel de um artigo da musa incorporada de Jack Ganssle. Enquanto isso diz firmware em todos os lugares, apenas mentalmente substituí-lo por software.

Compared to What?

Firmware is the most expensive thing in the universe. In his wonderful book "Augustine's Laws," Norman Augustine, former Lockheed Martin CEO, tells a revealing story about a problem encountered by the defense community. A high performance fighter aircraft is a delicate balance of conflicting needs: fuel range vs. performance. Speed vs. weight. It seems that by the late 70s fighters were at about as heavy as they'd ever be. Contractors, always pursuing larger profits, looked in vain for something they could add that cost a lot, but which weighed nothing.

The answer: firmware. Infinite cost, zero mass. Avionics now accounts for more than half of a fighter's cost. That's a chunk of change when you consider the latest American fighter, the F-22, costs a cool third of a billion a pop. Augustine practically chortles with glee when he relates this story.

But why is software so expensive? Tom DeMarco once answered this question with these three words: compared to what? He went on to discuss relatively boring business cases, but that answer has resonated in my mind for years. Compared to what? With software we routinely create product behaviors of unprecedented complexity. Sure, the code's expensive. But never in the history of civilization has anyone built anything so intricate.

Consider the following bubble sort, lifted shamelessly from Wikipedia and not checked for accuracy:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

It's a mere 110 non-space characters, perhaps tossed off in an hour or two. Suppose we didn't have software and had to implement a sort using some other strategy. What would it cost?

A mechanical engineer might boast that his profession built sorters long before computers. Consider IBM's 1949-era model 82 card sorter (http://www.columbia.edu/acis/history/sorter.html) with a throughput of 650 cards per minute, rather less than our code snippet might manage even on a 4 MHz Z80. The model 82, of course, only sorted one column of a card at a time; to completely sort a deck could take dozens of passes.

How long did it take to design and build this beast? Years, no doubt. And its functionality pales compared to our code which is so much faster and which can handle gigantic datasets. But that was 1949. How long would it take to build a bubble sort from electronic components - without FPGAs and VHDL, or a CPU?

In an hour I managed a rough block diagram, one above the chip level (blocks have names like "adder," "16 bit latch" and the like). But the sequencing logic is clearly pretty messy so I've just tossed in a PLD, assuming at some point it wouldn't be too hard to write the appropriate equations. And, yes, perhaps that breaks the no-programmable-logic rule, but to design and debug all that logic using gates in any reasonable amount of time is as unlikely as buck-a-gallon gas.

Assuming 16 bit words and addresses, the circuit will need around a dozen 16 bit latches, adders, and the like. Plus memory. And I have no idea how the unsorted data arrives into the RAM or how the results get exported. Those are unspecified design requirements. The software-only solution naturally resolves these requirements just by the act of writing the function prototype.

Translating the rough block diagram to a schematic might take a day. Then there's the time to design and produce a PCB, order and load parts (and change the design to deal with the unexpected but inevitable end-of-life issues), and then of course make the circuit work. We could be talking weeks of effort and a lot of money for the board, parts and appropriate test equipment.

All this to replace 7 little lines of code. Few real embedded programs are less than 10,000; many exceed a million. How much hardware and how much engineering would be needed to replace a real, super-sized computer program?

Consider a real program like a spreadsheet. How much circuitry would it take to make one without a processor? It could be the size of a city.

Firmware is the most expensive thing in the universe, but only because of the unimaginable complexity of the problems it solves. But it's vastly cheaper than any alternative. So when your boss irritably asks why the software takes so long, you know what to say. Compared to what?

Então ai! Software / firmware tem uma complexidade incomparável.

A engenharia e gerenciamento de software é fundamentalmente diferente de muitas outras áreas de engenharia. As entregas não são físicas e o processo de produção é o processo de design e desenvolvimento. Criar outra cópia de um software tem essencialmente um custo marginal zero; todo o custo é encontrado no desenvolvimento da primeira cópia.

Por causa da relativa juventude de engenharia e gerenciamento de software como disciplina, há algumas informações incorretas e falsidades que ainda são consideradas verdadeiras ( veja essa referência ) que impede o desenvolvimento de software e a engenharia como um todo.

Nem todos os desenvolvedores são criados iguais. Alguns são bons, outros são, bem, não.

Tente ler o código de outras pessoas o tempo todo para ter uma ideia do que estou dizendo. Muitas declarações lógicas extras podem adicionar risco. Esses riscos podem levar a maus comportamentos ou bugs. Não há instruções lógicas suficientes e agora você tem referências nulas. O bom programador entende isso e sabe quando fazer o que e onde. Mas ninguém é perfeito. As coisas são complexas. Adicione o trabalho mal pensado dos outros e é fácil ver como os projetos fogem.

As catedrais costumavam levar até 100 anos para serem construídas.

Alguns aviões da Airbus precisam de 1 milhão de linhas de código para funcionar.

Quanto mais tempo você estiver melhorando algo, mais melhorias você obterá, então dê à indústria de software alguns séculos de tentativa de erro para melhorar, e veremos o quanto é necessário desenvolver um sólido sólido. projeto sem erros ou falhas.

Grandes projetos geralmente ocorrem em grandes organizações. Se você nunca trabalhou em uma grande organização, há uma coisa que garante matar desempenho e produtividade: burocracia.

Recentemente, concluímos um projeto para implementar a autenticação por cartão inteligente. Foi originalmente estimado em três meses. Demorou 15 meses. Não houve nenhum custo, orçamento, escopo ou razões técnicas para o atraso. O escopo era realmente bastante restrito - apenas para contas com privilégios elevados (contas de administrador), cerca de 1.200 contas totais.

Outro fator significativo é seus parceiros de negócios. Isso inclui fornecedores. Se seus parceiros tiverem um problema que introduza um atraso em seu projeto, não há muitas opções que consertarão o problema de atraso. Eles não trabalham diretamente para você, e você pode não ser capaz de disparar essa pessoa em um parceiro que pode ser a causa. O parceiro pode ser demitido ou estar sujeito a penalidades ou desincentivos financeiros, mas isso não altera o fato de que o projeto sofreu um atraso. Foi exatamente isso que ocorreu com a Boeing quando eles realizaram uma gigantesca estratégia de fornecimento com o Boeing 787 Dreamliner .

Eu tenho uma versão mais curta para você:

Tudo o que é fácil de fazer ou simplificado, escrevemos um programa para fazer isso em vez de nós.

Depois, lute com o metaprocesso.

Não é verdade, por si só, mas todos os dias milhares de blogs são configurados, em vez de criar mecanismos de blog. Todo dia de trabalho, milhares de macros do Excel são gravadas, em vez de escrever aplicativos de banco de dados especialmente projetados para eles.

Existem muitos outros fatores - alguns deles mencionados aqui - mas eu gostaria de acrescentar este ponto à discussão.

Falta de responsabilidade ... As pessoas são processadas quando uma aeronave falha. A indústria de software declina qualquer responsabilidade em qualquer defeito de software, criando assim uma falta de incentivo para criar um produto robusto e seguro.

A maioria dos grandes projetos tem um alto grau de separabilidade de sub-projetos, onde você pode definir um pequeno número de restrições de projeto; todo o projeto funcionará quando esses subprojetos forem concluídos. Se algo der errado em um subprojeto, todo o esforço não será questionado; você procura formas alternativas de concluir o subprojeto (por exemplo, usar um mecanismo diferente).

Isso é possível, mas difícil, tanto na prática quanto na natureza humana, em projetos de software.

Em parte, outras indústrias aprenderam da maneira mais difícil que esse tipo de separabilidade é uma coisa boa. Por exemplo, se você for usar motores de avião Rolls Royce, não precisará usar parafusos Rolls Royce especiais e pontos de conexão que só funcionam com asas com um design específico e, em seguida, se tentar alternar para Pratt e Whitney, você tem que reprojetar toda a sua asa a partir do zero (o que, por sua vez, exige um redesenho completo da fuselagem, que por sua vez exige que você compre assentos diferentes, o que por sua vez exige que você compre um sistema de entretenimento a bordo diferente) qual...). Pode haver alguns vínculos - você não pode simplesmente trocar os mecanismos sem cuidado -, mas grandes projetos geralmente funcionam melhor quando essas coisas são minimizadas.

Eu postulo que grandes projetos de software projetados como um cluster de pequenos projetos de software com interfaces limpas entre si não não falharão com muita frequência, contanto que o grande projeto seja realmente resolvido pelo cluster de pequenas projetos. (É possível cometer um erro a esse respeito.)

Os sistemas de software de construção são muito diferentes da construção de estruturas físicas. Ou seja, a implementação é muito diferente. Enquanto, por exemplo, construindo um enorme petroleiro, você faz muitas tarefas relativamente simples (não é fácil!), Como soldar peças juntas por um robô ou manualmente, apertando todas as porcas e parafusos, pintar, fazer a decoração carregando em todos o equipamento e mobiliário e tal. Tudo isso é muito simples coisas para fazer, realmente.

No entanto, quando se trata de software, ele fica muito mais complexo . Por exemplo, exatamente como você implementa o login seguro e a credencial do usuário armazenando parte do produto? Quais bibliotecas e ferramentas você pode usar? Com quais bibliotecas e ferramentas você está familiarizado? Como exatamente você escreve a função hashing + salting e como você garante que ela é segura? Você pode fazer isso de muitas maneiras que é impossível definir qualquer padrão de design prático para este tipo de coisas. Sim, os ditos padrões de design do existem em uma escala menor como "melhores práticas", mas cada sistema de software é muito diferente dos outros, e o campo avança e muda em um ritmo tão rápido que é essencialmente impossível acompanhar.

Este não é o caso do software. Você não pode projetar o produto inteiro como uma entidade única e implementá-lo. O processo de design de software é geralmente iterativo e os objetivos e requisitos mudam à medida que o produto é implementado e testado. O desenvolvimento de software como um todo é um processo iterativo no qual as coisas geralmente mudam quando menos se espera, e muitas vezes tais mudanças impõem desafios que exigem mais trabalho, mais complexidade e infelizmente mais dinheiro, tempo e trabalho para acertar.

A definição de "grande projeto" é distorcida.

Um projeto grande, tecnicamente, pode ser entregue no prazo e, sem falhas, é algo que foi construído muitas vezes ao longo dos anos.

• Um clone do Pac-Man.
• Uma calculadora
• Um editor de texto

Tenho certeza que você está pensando ... "mas esses são projetos pequenos ! Um editor de texto é simples ." Eu discordaria de você. Computadores são escandalosamente complicados. Apenas instalar e configurar usuários em um sistema operacional pode ser difícil às vezes, e você nem sequer escreve o sistema operacional ou cria o hardware.

Os projetos dos quais você está falando são enormes projetos, semelhantes à exploração espacial. Como você sabe quanto tempo leva para desenvolver viagens entre galáxias? Em que modelo nos baseamos? Você tem os conhecidos conhecidos, os desconhecidos conhecidos, os desconhecidos e, finalmente, os desconhecidos desconhecidos, que por acaso surgem muito no desenvolvimento de software.

Eu acho que o problema é de expectativa. Só porque a tecnologia está lá não significa que ela será bem sucedida (ou sábia para usar) por um tempo. Se outras indústrias se comportassem como as indústrias de software, teríamos aspiradores com buracos negros para venda até o final da década. Ou algum "visionário" teria os recursos para construir uma base lunar e decidir que um Starbucks realmente "completaria" a experiência para os visitantes. Eu não acho que o problema seja a indústria de software, mas as expectativas colocadas em .

Embora dificilmente seja a única coisa que poderia ser mencionada, acho que uma coisa básica vale a pena ressaltar. A maioria dos produtos se destina a se adequar ao comportamento existente. Até mesmo um produto que é um avanço radical (por exemplo, o carro) é geralmente construído para se adequar ao comportamento existente, e simplesmente torná-lo um pouco mais simples / mais fácil / mais barato / o que quer que seja para fazer isso. Sim, muitas vezes há alguns efeito colateral no comportamento existente (por exemplo, obter combustível para o carro em vez de comida para os cavalos), mas a maior parte deste último tende a ser um efeito colateral menor.

Em suma, projetar o software em si é a parte mais fácil do trabalho. A parte difícil é redesenhar os trabalhos das pessoas para eles. Isso é difícil de começar; fazer isso de uma maneira que não apenas funcione, mas também seja aceito é muito mais difícil ainda.

O Airbus A380 não foi um projeto de sucesso como você mencionou. Por acaso, trabalho em uma empresa de CAD / CAM, e me disseram que (também tivemos o priojecto da Airbus) foi adiada por alguns anos, porque eles estavam usando diferentes versões de software em diferentes empresas. Ou seja, diferentes partes estavam sendo projetadas em diferentes partes do mundo. E enquanto integrando eles vieram a saber que todo o design não pode ser integrado, então eles têm que reprojetá-lo em uma versão. Então, olhando para ele, não acho que tenha sido bem sucedido. Se tivesse chegado 2-3 anos antes, teria sido um divisor de águas para a Airbus.

Também em relação ao software robusto, você olha para qualquer avião, carro (ABS, EPS, controle climático, etc.) ou ônibus espacial. Eles possuem mais de 50% de software que os executam e acreditam que são muito robustos. É que estamos mais perto do software e há muitos mais programas de software, por isso vemos mais erros neles.

Visite: link e ver o quanto o Airbus A380 foi bem sucedido.

Engenheiro de software aqui, com formação em engenharia, e uma esposa que trabalha em construção. Tivemos longas discussões (e argumentos) sobre as diferenças de nossos trabalhos.

A engenharia de software é sobre projetar coisas novas . Quase tudo básico foi feito em uma biblioteca de código aberto em algum lugar. Em quase todos os trabalhos em que um engenheiro de software é contratado, ela precisa projetar algo que não existe.

Em algo como a construção e a maioria das formas de engenharia, as coisas que de outra forma estariam em uma 'biblioteca' no software já estão totalmente projetadas. Quer construir uma torre? Basta copiar e colar os planos de uma estrutura existente, com algumas modificações.

Na verdade, uma das principais razões pelas quais decidi não me tornar engenheiro é que você gasta a maior parte do tempo projetando uma melhoria de 10% em uma invenção existente, quando esse mesmo tempo poderia ser usado para programar algo mais visível, como uma rede social.

Não há muitos projetos novos em engenharia; um engenheiro extremamente qualificado é alguém que pode manipular um projeto existente em algo novo ou aperfeiçoá-lo. Mas espera-se que quase todos os programadores modifiquem projetos, hackem-nos ou criem algo novo.

Veja como os padrões mudaram completamente, da montagem para C para C ++ para Java, JavaScript, C # , PHP e assim por diante. Não há muitos códigos que possam ser reciclados de 10 ou 20 anos atrás. Isso é muito diferente de dizer ... a indústria automotiva ou aeronáutica quando você pode continuar melhorando em projetos de décadas atrás.

O gerenciamento de projetos é notoriamente difícil em software . As estimativas de tempo são mais bem feitas por pessoas fazendo o trabalho, mas quando estão ocupadas fazendo estimativas, elas não estão escrevendo código. Isso leva as pessoas a evitar qualquer gerenciamento de projetos.

Geralmente, muito código depende de pessoas específicas e, se essas pessoas estiverem atrasadas ou impossibilitadas de executar, o código não será adiantado. Por outro lado, se você quiser construir um carro, basta contratar pessoas diferentes para montar os pneus, o chassi, a bateria, o motor e assim por diante. Estruturas orientadas a objeto e existentes tornam isso possível, mas pode não ser prático quando você está projetando tudo do zero.

Falhas podem ser permitidas no software . O teste pode ser caro. No software, é muito tentador pular todo esse teste, quando você pode simplesmente consertar uma falha. Na maioria das formas de engenharia, um 'acidente' pode ser fatal.

Você tem métodos de programação que usam testes extensivos, como programação extrema (que foi realmente usada em megaprojetos de software). Mas com prazos apertados (que podem ser feitos de propósito), é tentador pular toda essa programação e lançar com bugs. O estilo de "sempre corrigir todos os bugs" de Joel Spolsky economizará mais tempo a longo prazo, mas os indisciplinados irão ignorar isso e falhar.

Os projetos pequenos são melhores . Minha esposa uma vez me pediu para conseguir um emprego em uma grande empresa. Acabou em um argumento de que grandes empresas são más empresas ... para ela, uma grande empresa tinha muitos recursos, experiência, gerenciamento de projetos funcionais e os procedimentos corretos. Para mim, uma grande empresa é um dinossauro, onde a maior parte do tempo é gasto na correção de códigos, testes e documentação.

Eu já vi projetos de TI de um milhão de dólares trabalhando por menos de 10 pessoas. Mais pessoas teriam desacelerado o projeto e adicionado burocracia desnecessária. O WhatsApp é um exemplo de um projeto 'pequeno' que vale bilhões de dólares. Não é que grandes projetos não sejam possíveis, mas você simplesmente não precisa de milhares de pessoas para produzir bilhões de dólares em software.

Uma razão para isso é que a evolução de software é um ciclo de feedback positivo, porque o software (linguagens de programação, ferramentas de construção, IDEs) é usado para construir software. É o exemplo mais óbvio para a lei de aceleração dos retornos de Ray Kurzweil, resultando em progresso na velocidade exponencialmente crescente. Depois de ter dominado uma estrutura, linguagem de programação e protocolo de comunicação, é a hora de seguir em frente para o próximo.

Se os aviões fossem construídos como software, estaríamos mudando o material com todos os outros modelos, dobrando sua capacidade e velocidade a cada 18 meses, substituindo a tecnologia do motor de cada novo modelo por algo recém inventado, acrescentando a capacidade de nadar e busca por vida extraterrestre.

Ah, e idealmente ele ouve comandos de voz e funciona como uma sala de cinema totalmente imersiva, uma arena de paintball e um clube noturno com um quarto escuro quando a sua viagem de trabalho termina. A mesma coisa! (A empresa que construiu aviões que acabou de fazer você confiavelmente de A para B caiu de barriga um ano depois que o cinema, o paintball e a boate apareceram.)

Para mim, o principal problema que a engenharia de software enfrenta são os casos de uso, o usuário e as plataformas cruzadas.

Casos de uso

Quantos casos de uso tem um avião? A maior parte é apenas para voar de um lugar para outro. Talvez existam mais, como radar, controle de tráfego, etc., mas o caso de uso é claro e não muito. Na engenharia de software, nos deparamos com requisitos pouco claros e usuários que não sabem o que querem. Usuário diferente precisa de configuração / fluxo diferente, um avião pode ser personalizado como o usuário quiser (eu quero ter tv e geladeira!)?

Utilizador

Quem opera um avião? Um piloto, um copiloto, alguns comissários (se contados) e operadores de torre. Eles são todos profissionais e têm suas descrições de trabalho claras. Software são usados por noobs e manequins, para não mencionar hackers e crackers maléficos, enquanto ainda precisam ser integráveis com outros módulos (como OpenID ou Google AdSense ). Se um avião pode ser operado por manequins enquanto ainda sobrevive de mísseis ou ladrões ninja, então você pode dizer que o avião tem a mesma qualidade com o software.

Plataformas cruzadas

Um avião voa apenas no céu da Terra. Eu não tenho certeza sobre como eles lidam com o clima nebuloso ou ventoso ou quente, frio e úmido, mas um avião não é projetado para voar em diferentes níveis de gravitação (eu ficarei surpreso se puder voar para Mars ). Às vezes, um aplicativo deve sobreviver a diferentes plataformas, como o Internet Explorer, o Google Chrome , Firefox e Safari para o navegador (desculpe Opera ), ou Windows XP / 7/8, ou Linux para o nível do sistema operacional. Sem mencionar os dispositivos móveis e diferentes resoluções e orientações.

Se você acha que outras indústrias concluem projetos sem incidentes, você deve ler a história do prédio do Citigroup Center, construído em 1977. Mesmo após quase 7 anos de planejamento e construção, o prédio foi concluído com uma séria falha de projeto que teria causado colapso de um evento de tempestade esperado a cada 16 anos.

In other words, for every year Citicorp Center was standing, there was about a 1-in-16 chance that it would collapse.

Os designers originais não sabiam dos problemas, mas, por sorte, ele foi pego por um estudante que estudava o prédio.

everything seemed just fine—until, as LeMessurier tells it, he got a phone call. According to LeMessurier, in 1978 an undergraduate architecture student contacted him with a bold claim about LeMessurier’s building: that Citicorp Center could blow over in the wind.

Reparos foram feitos literalmente na cobertura da noite envolvendo a menor quantidade de pessoas para manter o sigilo da falha do projeto.

Um plano de evacuação de emergência foi preparado para o raio de 10 quarteirões ao redor do prédio.

They welded throughout the night and quit at daybreak, just as the building occupants returned to work.

The story remained a secret until writer Joe Morgenstern overheard it being told at a party, and interviewed LeMessurier. Morgenstern broke the story in The New Yorker in 1995.

O que levanta a questão; quantas outras falhas de projeto fatais em projetos foram secretamente reparadas ou ignoradas sem reconhecimento público.

• A falha de design que quase apagou um arranha-céu de Nova York (slate.com)
• Citigroup Center (wikipedia.com)