Por que o setor de TI não pode entregar projetos grandes e sem falhas tão rapidamente quanto em outros setores?

Depois de assistir à série MegaStructures da National Geographic , fiquei surpreso com a rapidez com que grandes projetos são concluídos. Depois que o trabalho preliminar (design, especificações, etc.) é feito no papel, a realização de grandes projetos leva apenas alguns anos ou, algumas vezes, alguns meses .

Por exemplo, o Airbus A380 "lançado formalmente em 19 de dezembro de 2000" e "no início de março de 2005" , a aeronave já havia sido testada. O mesmo vale para grandes petroleiros, arranha-céus, etc.

Comparando isso com os atrasos na indústria de software, não consigo deixar de me perguntar por que a maioria dos projetos de TI é tão lenta ou mais precisamente por que eles não podem ser tão rápidos e sem falhas, na mesma escala, com número suficiente de pessoas?

Projetos como o Airbus A380 apresentam ambos:

• Principais riscos imprevistos: embora essa não seja a primeira aeronave construída, ela ainda ultrapassa os limites da tecnologia e as coisas que funcionaram bem em aviões menores podem não funcionar em aviões maiores, devido a restrições físicas; Da mesma forma, são utilizadas novas tecnologias que ainda não foram usadas, porque, por exemplo, não estavam disponíveis em 1969 quando o Boeing 747 foi concluído.

• Riscos relacionados a recursos humanos e gerenciamento em geral: pessoas que param no meio do projeto, incapacidade de alcançar uma pessoa porque ela está de férias, erros humanos comuns, etc.

Com esses riscos, as pessoas ainda realizam projetos como esses grandes aviões em um período muito curto de tempo e, apesar dos atrasos na entrega, esses projetos ainda são extremamente bem-sucedidos e de alta qualidade.

Quando se trata de desenvolvimento de software, os projetos não são tão grandes e complicados quanto um avião de passageiros (tecnicamente e em termos de gerenciamento) e apresentam riscos um pouco menos imprevisíveis do mundo real.

Ainda assim, a maioria dos projetos de TI é lenta e atrasada , e adicionar mais desenvolvedores ao projeto não é uma solução (passar de uma equipe de dez desenvolvedores para dois mil às vezes permitirá entregar o projeto mais rapidamente, às vezes não, e às vezes prejudicará apenas a projeto e aumente o risco de não finalizá-lo).

Aqueles que ainda são entregues podem conter muitos bugs, exigindo service packs consecutivos e atualizações regulares (imagine "instalar atualizações" em todos os Airbus A380 duas vezes por semana para corrigir os bugs no produto original e impedir que a aeronave caia).

Como essas diferenças podem ser explicadas? Isso se deve exclusivamente ao fato de o setor de desenvolvimento de software ser jovem demais para poder gerenciar milhares de pessoas em um único projeto, a fim de entregar produtos em grande escala, quase sem falhas, com muita rapidez?

A Marcha da Morte, de Ed Yourdon, aborda várias dessas perguntas do tipo meta.

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

• Padronização e detalhamento dos itens de trabalho.

  • Isso certamente melhorou, mas as construções de design ainda não existem para abrir um grande sistema. De certa forma, o software não pode sequer concordar com o que é necessário para um determinado projeto, e muito menos ser capaz de dividir as coisas em componentes.
  • Aeroespacial, construção civil, automóveis, etc. todos têm arquiteturas muito orientadas a componentes com interfaces razoavelmente rígidas para permitir um desenvolvimento totalmente paralelo. O software ainda permite muito sangramento nas áreas correspondentes.

• Um grande corpo de projetos semelhantes e bem-sucedidos. O A380 não foi o primeiro grande avião que a Airbus construiu. Existem muitos aplicativos de software grandes por aí, mas muitos deles sofreram dramaticamente em um aspecto ou outro e nem chegariam perto de serem chamados de "bem-sucedidos".

• Um grande corpo de designers e construtores que trabalharam em vários projetos semelhantes e bem-sucedidos. Relacionado à questão do projeto bem-sucedido, não ter o talento humano que já esteve lá, faz 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. Grandes projetos de software raramente se repetem. Cada kernel do SO é significativamente diferente. Veja a disparidade nos sistemas de arquivos. E, por falar nisso, quantos sistemas operacionais verdadeiramente únicos existem? Os grandes se tornam clones de um item base em algum momento. AIX , Solaris , HP-UX , ... arauto de volta a AT & T System V . O Windows teve uma quantidade incrível de arrastar adiante em cada iteração. As variantes do Linux geralmente voltam ao mesmo núcleo que o Linus iniciou. Eu trago isso à tona, porque as variantes tendem a se propagar mais rapidamente do que os sistemas operacionais exclusivos e exclusivos.

• Estimativa muito ruim do projeto. Como o fator de repetibilidade é tão baixo, é difícil projetar qual será o tamanho e o tempo que 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, são geradas expectativas irreais em relação aos prazos.

• O controle de qualidade / controle de qualidade não é enfatizado tão fortemente quanto poderia ou deveria ser para projetos maiores. Isso remonta a ter interfaces mais frouxas entre componentes e a não ter especificações rígidas sobre como os componentes devem funcionar. Essa frouxidão permite conseqüências não intencionais e insetos.

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

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

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

Muitos projetos em outros setores demoram muito mais do que o inicialmente estimado, 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 fabricação digna de nota. Construir o componente final é (comparativamente) barato, e a replicação desse produto final é perfeita e efetivamente gratuita - você copia os artefatos de construção.

Para apontar algumas figuras:

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 acredito 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 do tipo humano, projetados e desenvolvidos;
3. Recursos insuficientes são gastos na fase de arquitetura e design ;
4. Imaturidade de campo - a engenharia de software é uma disciplina relativamente jovem em comparação com outras irmãs de engenharia; isso tem duas implicações: a) poucas heurísticas e boas práticas; b) Poucos 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 conforme necessário; em vez disso, o teste é usado. Isso vale em outros campos da engenharia que dependem mais fortemente da matemática; a razão disso é tão complexa;
6. Rush - muitos gerentes têm prazos inatingíveis; portanto, a qualidade do código fica em segundo lugar, por causa do prazo.

Respondendo estritamente à pergunta - costumo acreditar que outras pessoas têm expectativas muito altas (especialmente no tempo de entrega) dos programadores e não entendem exatamente o quão difícil é a programação de grandes softwares.

A premissa da pergunta é um pouco falha. Tanto o A380 quanto o Boeing 787 foram entregues anos depois.

No caso do A380, grande parte do atraso foi causado pelas unidades francesa e alemã da Airbus, usando versões diferentes e ligeiramente incompatíveis do software de design CATIA . Isso se manifestou incompativelmente como chicotes elétricos que não se encaixavam perfeitamente no avião.

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

O Boeing 787 também sofreu com atrasos relacionados ao software, mas a maioria de seus problemas eram problemas de aviões novos mais tradicionais, como controle de peso e entrega de peças abaixo do padrão pelos fornecedores.

Tanto o A380 quanto o B787 tiveram que modificar seus projetos de asas depois que a aeronave inicial teve problemas estruturais.

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

Cara de arranha-céu aqui. Não tenho certeza se posso responder à sua pergunta, mas certamente posso esclarecer alguns itens do tópico. Edifícios de fato ocorrem muito rápido. Uma restrição importante é a localidade (regulamentos). Mas, em geral, são necessários de 3 a 10 anos para um prédio alto do início ao fim.

Eu acho que comparar um novo prédio com um novo projeto de software não é muito preciso. Um novo prédio está mais próximo de uma nova versão de um kernel ou sistema operacional. Nesse sentido, o desenvolvimento de software é muito mais rápido. Nunca construímos do zero, pois essa será uma tarefa de alto risco que o cliente nunca assinaria. A maioria dos projetos e desenvolvimentos em edifícios é derivada de projetos comprovados e concluídos.

Por experiência pessoal, apenas um em cada dez projetos é construído. O processo é mais orientado para o desenvolvimento do que para o design; portanto, no momento em que algo como o preço do aço sobe, todo o projeto sai pela janela ou é projetado, pois o design é o componente mais barato do processo.

O projeto leva um mês para o esquema 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 estruturais, engenheiros eólicos, engenheiros de serviços, consultores de quantidade e custo, topógrafos, engenheiros de acessibilidade e a lista continua ...

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

Em termos de complexidade, existem diferenças, mas no geral é talvez o mesmo. Não apenas temos unidades inter-relacionadas e vários níveis de abstrações e interfaces em camadas, mas também as pessoas são muito especializadas em pequenas partes do processo que dificultam a comunicação.

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

No geral, minha estimativa (potencialmente errada), conforme a pergunta do OP, é que a programação é mais uma arte do que engenharia. Por que as pessoas gostariam de fazê-lo de graça, encontravam expressão e elegância nele? A ciência da computação também é (como na lata) mais uma ciência do que engenharia. Por que você tentaria provar algoritmos em vez de apenas remendar partes existentes e trabalhar para fazer as coisas funcionarem? Não tenho certeza se isso faz algum sentido; Eu não sou um cara de software.

Um aspecto que me impressiona no 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 há poucas tolerâncias. É difícil trabalhar mentalmente para resolver isso, e alguns se safam disso abandonando a complexidade. Se nada mais, isso pode ter algo a ver com isso?

Então, quanto tempo o design desses levou? Ano? Dois? Dez anos? O design é a parte mais complexa da construção de algo, a construção em si é fácil.

Com base neste artigo , está sendo entendido lentamente que o desenvolvimento de software é principalmente um processo de design em que 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 alterações nos requisitos podem resultar em grandes mudanças na arquitetura geral do projeto. Esse entendimento é a base para metodologias ágeis que se concentram na melhoria da qualidade do código como documento final do projeto e na realização de testes e depuração como parte do processo de design, assim como eles testam modelos de avião em túneis de vento.

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

A razão pela qual os projetos de software terminam com grandes atrasos e custos inflados é porque os gerentes ainda pensam que podem estimar, prever e planejar um processo de design desse tipo. Isso sai pela culatra com mais frequência do que é realmente válido. Eles ainda pensam que, ao vincular as pessoas a um processo rígido de construção, 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 design do Airbus A380, alguém apareceu em uma reunião e disse: "Heh, poderia construí-lo como um triplano?" Outros se uniram dizendo: "Sim, sim. Um triplano. Mais asas são melhores". Nos próximos anos, passamos a transformar o design do A380 em um triplano. Em outra reunião, alguém diz: "Um triplano? Isso é velho. Queremos um biplano. Apenas remova uma das asas".

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

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

Como alguém com formação em engenharia mecânica trabalhando em TI, sempre me perguntei sobre os motivos da baixa taxa de sucesso em TI.

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

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

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

Isso inevitavelmente leva a produtos pontuais, que são caros de desenvolver e atender, são propensos a erros e falham de maneira imprevisível em condições incertas. E por causa disso, é claro, esses produtos são muito mais obsoletos, escritos e substituídos a um custo igualmente grande por apenas um pouco melhores. O que a TI precisa é o equivalente à revolução industrial, que transformou os artesãos da meia-idade em fábricas eficientes.

Dito isto, existem fatores que tornam a TI verdadeiramente única. Ao contrário dos outros setores mencionados, a TI é realmente onipresente: é usada em todos os aspectos da nossa vida moderna. Portanto, é um pequeno milagre que a TI tenha alcançado tanto progresso e seja capaz de fornecer os resultados que obtém.

Receio não concordar com sua afirmação.

Airbus e Boeing são dois exemplos de empresas que constroem aviões. Quantas empresas que constroem aviões existem? Muito poucos, se você compará-lo com quantas empresas constroem software.

É igualmente fácil ferrar um projeto de avião como ferrar um projeto de software. Se apenas a barreira de entrada era tão baixa no setor de construção de aeronaves quanto no setor de software, você certamente verá muitos projetos de aeronaves com falha.

Olhe para carros; Existem fabricantes de alta qualidade que constroem automóveis muito duráveis ​​e altamente avançados (como Land Rover, Mercedes) e outros que fabricam carros que não duram um ano sem precisar repará-los (como Kia ou Cherry). Este é um exemplo perfeito de uma indústria com barreira de entrada um pouco menor, quando você começa a ter participantes mais fracos.

Software não é diferente. Por outro lado, você tem muitos produtos com erros, Windows, Office, Linux, Chrome ou Pesquisa do Google são projetos de alta qualidade, entregues no prazo e com nível de qualidade semelhante ao de uma aeronave.

O outro ponto que muitas pessoas perdem é a quantidade de manutenção necessária para manter um carro, um navio-tanque ou uma aeronave que consideramos apenas um fato da vida. Todo avião deve passar por um exame técnico antes de decolar. Você precisa fazer o check-up do seu carro a cada quilômetro e fazer coisas regulares, como trocar o óleo, trocar os pneus.

O software também precisa disso. Se apenas as pessoas gastassem tanto tempo em diagnósticos, prevenção ou auditoria do estado e da qualidade do software quanto gastam com produtos mecânicos / físicos, eu esperaria muito menos declarações como essas. Você lê os logs do seu aplicativo sempre que o inicia? Bem .. se fosse uma aeronave você teria que ;-)

Os blocos de construção digitais podem ser 1 ou 0. Não há intervalo entre eles.

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

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 parece (ocasionalmente) que somos um bando de amadores que não têm idéia do que estamos fazendo. Não gosto de explicações que culpam os 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 patch é barato, comparado à reconstrução de um arranha-céu ou ao recall de todos os celulares vendidos.

Isso criou uma cultura em que os bugs fazem parte da vida cotidiana . Eles são aceitos com um encolher de ombros. Embora alguns erros sejam provavelmente inevitáveis, eles devem dominar nosso trabalho diário ? Entendo completamente os gerentes que não acham que o controle de qualidade vale a pena, precisamente porque esperam erros de qualquer maneira. Eu não entendo programadores que não fazem todo o esforço para produzir código sem erros, porque corrigir bugs é chato como o inferno.

Em essência, acredito que seja um problema de cultura e espero que isso mude.

Os padrões e práticas de engenharia são muito diferentes em TI (como um setor independente) e no setor aeroespacial . Talvez isso seja mais facilmente compreendido considerando-se como os profissionais de TI reagem ao encontrar documentos de padrões para TI no setor aeroespacial . Por exemplo, os Padrões Joint Strike Fighter C ++ que percorreram a Internet nos últimos tempos.

Muitos expressam perplexidade ou resignação melancólica (gostariam que pudéssemos fazer isso); e muitos respondem com zombaria, alegando que não há maneira prática de fornecer produtos de consumo dessa maneira. Isso pode até estar certo, dadas as expectativas, não dos consumidores, mas da administração. Existe muita desconfiança em relação aos codificadores que apenas codificam e codificam por algumas semanas, sem demonstrar nada. Deus ajude o programador que apenas projeta algo por duas semanas. Não é assim com os aviões.

No software, as pessoas realmente esperam ter algo agora. Claro, o raciocínio continua, levará um tempo para que ele seja realmente sólido; mas não podemos ter algo complexo descrito em termos simples em uma semana? Aprende-se, também, que coisas complexas descritas em termos honestos e complexos raramente excitam a imaginação; e, portanto, muitos engenheiros acabam sendo cúmplices em um mundo imaginado de coisas realmente simples sendo reunidas de maneiras criativas (em oposição a um mundo de coisas difíceis sendo muito bem-sucedidas).

Algumas coisas minhas:

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

Os projetos de software, por outro lado, quase sempre começam do zero, com apenas algumas pequenas estruturas / auxiliares.

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 ser concluído, e eles optaram por negligenciar quaisquer grandes avanços que possam acontecer nesse período. (O 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 o software, você precisa ser muito ágil, se eu iniciar um projeto enorme agora e levar três anos para desenvolvê-lo sem nenhuma alteração, as chances são muito altas de que eu esteja contando com a tecnologia que não está mais disponível ou que meu produto esteja completamente desatualizado. Por sua vez, isso oferece muitos problemas.

3- Ciclo de lançamento e versões. - Um avião precisa ser completamente terminado quando é "liberado". Não há versões beta estáveis, versões noturnas ou similares. Além disso, uma vez feito, ele pode ser modificado apenas em pequenas quantidades. Você não pode adicionar um nível adicional com 100 assentos a um boeing existente, simplesmente não é possível.

Por outro lado, o software possui alterações incrementais que geralmente são apenas "construçõ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 comporta 50 toneladas adicionais".

Eu acho que a resposta é bastante simples:

1) A construção e a implementação físicas existem há tanto tempo quanto as pessoas - 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 totalmente novo e diferente, não tem mais de 50 anos - ainda não tivemos tempo suficiente para descobrir tudo.

2) A construção virtual é mais difícil - você precisa "ver" coisas em sua mente que não têm realidade física. Requer que você analise e abstraia muitas informações antes mesmo de saber como o seu produto deve ser e as etapas necessárias para criá-lo. Não é assim quando se constrói uma ponte ou um edifício.

3) Muitas vezes, é muito mais difícil encontrar a fonte de uma falha ou bug do software do que na engenharia física. Se uma viga se dobra, você vê onde está se dobrando e os suportes que a seguram e falham, etc. Encontrar um defeito de software pode exigir a análise de uma grande quantidade de código e processos de interação - difícil, demorado e não vinculado ao leis da física e da matemática da maneira que as estruturas físicas são.

Tentarei responder usando uma cópia literal de um artigo da musa incorporada de Jack Ganssle. Enquanto isso indica firmware em qualquer lugar, substitua-o mentalmente por software.

Comparado com o quê?

Firmware é a coisa mais cara do universo. Em seu maravilhoso livro "Augustine's Laws", Norman Augustine, ex-CEO da Lockheed Martin, conta uma história reveladora sobre um problema encontrado pela comunidade de defesa. Um avião de caça de alto desempenho é um delicado equilíbrio de necessidades conflitantes: faixa de combustível x desempenho. Velocidade vs. peso. Parece que no final dos anos 70 os lutadores estavam quase tão pesados ​​quanto jamais seriam. Os empreiteiros, sempre buscando lucros maiores, procuravam em vão algo que poderiam acrescentar que custava muito, mas que nada pesava.

A resposta: firmware. Custo infinito, massa zero. A Avionics agora representa mais da metade do custo de um caça. Isso é um pedaço de mudança quando você considera o mais recente caça americano, o F-22, que custa um terço legal de um bilhão por pop. Agostinho praticamente ri de alegria quando conta essa história.

Mas por que o software é tão caro? Tom DeMarco respondeu uma vez a esta pergunta com estas três palavras: comparado a quê? Ele continuou discutindo casos de negócios relativamente chatos, mas essa resposta ressoou em minha mente por anos. Comparado com o que? Com o software, criamos rotineiramente comportamentos de produtos de complexidade sem precedentes. Claro, o código é caro. Mas nunca na história da civilização alguém construiu algo tão intrincado.

Considere a seguinte classificação de bolhas, levantada descaradamente da Wikipedia e não verificada quanto à precisão:

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]);

}

São apenas 110 caracteres não-espaciais, talvez jogados fora em uma hora ou duas. Suponha que não tínhamos software e tivemos que implementar uma classificação usando alguma outra estratégia. Quanto custaria?

Um engenheiro mecânico pode se gabar de que sua profissão construiu classificadores muito antes dos computadores. Considere o classificador de cartões modelo 82 da época da IBM de 1949 ( http://www.columbia.edu/acis/history/sorter.html ) com uma taxa de transferência de 650 cartões por minuto, um pouco menos do que nosso trecho de código pode gerenciar mesmo em 4 MHz Z80. O modelo 82, é claro, classificou apenas uma coluna de um cartão de cada vez; classificar completamente um baralho pode levar dezenas de passes.

Quanto tempo levou para projetar e construir esta fera? Anos, sem dúvida. E sua funcionalidade empalidece em comparação com nosso código, que é muito mais rápido e capaz de lidar com conjuntos de dados gigantescos. Mas isso foi em 1949. Quanto tempo levaria para criar uma espécie de bolha a partir de componentes eletrônicos - sem FPGAs e VHDL, ou uma CPU?

Em uma hora, gerenciei um diagrama aproximado de blocos, um acima do nível do chip (os blocos têm nomes como "somador", "trava de 16 bits" e similares). Mas a lógica de seqüenciamento é claramente bastante confusa, então acabei de lançar um PLD, assumindo que em algum momento não seria muito difícil escrever as equações apropriadas. E, sim, talvez isso quebre a regra da lógica não programável, mas projetar e depurar toda essa lógica usando portas em qualquer quantidade de tempo razoável é tão improvável quanto o gás de galão.

Assumindo palavras e endereços de 16 bits, o circuito precisará de cerca de uma dúzia de travas de 16 bits, somadores e similares. Além de memória. E não tenho ideia de como os dados não classificados chegam à RAM ou como os resultados são exportados. Esses são requisitos de design não especificados. A solução somente de software resolve esses requisitos naturalmente apenas pelo ato de escrever o protótipo da função.

Traduzir o diagrama de blocos aproximado para um esquema pode levar um dia. Depois, é hora de projetar e produzir uma PCB, solicitar e carregar peças (e alterar o design para lidar com os problemas inesperados, mas inevitáveis ​​de fim de vida) e depois fazer o circuito funcionar. Poderíamos estar conversando semanas de esforço e muito dinheiro para o conselho, as peças e o equipamento de teste apropriado.

Tudo isso para substituir 7 pequenas linhas de código. Poucos programas incorporados reais são inferiores a 10.000; muitos excedem um milhão. Quanto hardware e quanta engenharia seria necessária para substituir um programa de computador de tamanho grande e real?

Considere um programa real como uma planilha. Quanto circuito seria necessário para criar um sem um processador? Pode ser do tamanho de uma cidade.

O firmware é a coisa mais cara do universo, mas apenas devido à complexidade inimaginável dos problemas que resolve. Mas é muito mais barato que qualquer alternativa. Portanto, quando seu chefe pergunta irritadamente por que o software leva tanto tempo, você sabe o que dizer. Comparado com o que?

Então aí! Software / firmware possui complexidade incomparável.

A engenharia e o gerenciamento de software são fundamentalmente diferentes 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 juventude relativa da engenharia e gerenciamento de software como disciplina, existem algumas informações erradas e falsas que ainda são consideradas fatos ( consulte esta referência ), o que dificulta o desenvolvimento e a engenharia de software como um todo.

Nem todos os desenvolvedores são criados igualmente. 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 riscos. 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 planejado de outras pessoas 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ê aprimora alguma coisa, mais melhorias obtém, portanto, dê à indústria de software alguns séculos de tentativa de erro para melhorar, e veremos quanto é necessário para desenvolver um projeto sólido e sólido sem bugs ou falhas.

Projetos grandes geralmente ocorrem em grandes organizações. Se você nunca trabalhou em uma organização grande, há uma coisa que é garantida para diminuir o desempenho e a produtividade: burocracia.

Surpreendentemente, muitas pessoas não sabem o que é burocracia (geralmente é confundida com política), ou mesmo se / quando têm um problema de burocracia.

Concluímos recentemente um projeto para implementar a autenticação com cartão inteligente. Foi originalmente estimado em três meses. Demorou 15 meses. Não houve custo, orçamento, escopo ou motivos técnicos para o atraso. O escopo era realmente bastante restrito - apenas para contas com privilégios elevados (contas de administrador), cerca de 1.200 contas no total.

Outro fator significativo são seus parceiros de negócios. Isso incluiria fornecedores. Se seus parceiros tiverem um problema que introduza um atraso no seu projeto, não há muitas opções que realmente solucionem o problema de atraso. Eles não funcionam diretamente para você e você pode não conseguir demitir essa pessoa contra um parceiro que possa ser a causa. O parceiro pode ser demitido ou pode estar sujeito a sanções financeiras ou desincentivos, mas isso não altera o fato de o projeto ter sofrido um atraso. Foi exatamente isso que ocorreu com a Boeing quando empreenderam uma estratégia gigantesca 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 fazê-lo, em vez de nós.

E então lute com o meta-processo.

Não é tão verdade assim, mas todos os dias são criados milhares de blogs, em vez de escrever os mecanismos de blog. Todos os dias de trabalho, milhares de macros do Excel são gravadas, em vez de criar aplicativos de banco de dados especialmente projetados para eles.

Existem muitos outros fatores - alguns deles mencionados aqui -, mas eu queria acrescentar esse ponto à discussão.

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

A maioria dos projetos grandes possui um alto grau de separabilidade de subprojetos, onde é possível definir um pequeno número de restrições de design; todo o projeto funcionará quando esses subprojetos forem concluídos. Se algo der errado em um subprojeto, todo o esforço não é posto em questão; você apenas procura maneiras alternativas de concluir o subprojeto (por exemplo, use 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ê usar motores de aeronaves Rolls Royce, não precisará usar parafusos e pontos de fixação especiais Rolls Royce que funcionem apenas com asas com um design específico e, se tentar mudar para Pratt e Whitney, é necessário reprojetar sua asa inteira do zero (o que, por sua vez, exige um reprojeto completo da fuselagem, o que 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 algumas ligações - você não pode simplesmente trocar de mecanismo sem se preocupar -, 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 falharão com freqüência, desde que o grande projeto seja realmente resolvido pelo cluster de pequenos projetos. (É possível cometer um erro a esse respeito.)

A construção de sistemas de software é muito diferente da construção de estruturas físicas. Ou seja, a implementação é muito diferente. Enquanto, por exemplo, construindo um caminhão-tanque enorme, você executa muitas tarefas relativamente simples (embora não sejam fáceis!), Como soldar peças juntas por um robô ou manualmente, apertar todas as porcas e parafusos, pintar, fazer a decoração carregando todas as peças necessárias. o equipamento e mobiliário e tal. Tudo isso é realmente muito simples de se fazer.

No entanto, quando se trata de software, fica muito mais complexo . Por exemplo, como exatamente você implementa a parte segura do logon seguro e do armazenamento de credenciais do usuário? Quais bibliotecas e ferramentas você pode usar? Com quais bibliotecas e ferramentas você conhece? Como exatamente você escreve a função hash + salga e como garante que ela seja segura? Você pode fazer isso de tantas maneiras que é impossível definir padrões de design práticos reais para esse tipo de coisa. Sim, os referidos padrões de design que existem em uma escala menor, como "melhores práticas", mas cada sistema de software único é muito diferente dos outros, e os avanços de campo e mudanças no ritmo tão rápido que é essencialmente impossível manter-se.

Ao construir uma casa, você realmente não se depara com esses problemas, quando percebe que as principais paredes de suporte parecem inadequadas e precisam ser substituídas, exigindo que você demole o progresso até agora e comece a partir da base refazendo as paredes de suporte . Você lida com esses problemas na fase de projeto , porque é relativamente simples prever que tipo de paredes de suporte seu edifício precisa.

Esse não é o caso do software. Você não pode realmente projetar o produto inteiro como uma única entidade e implementá-lo. O processo de design do software é geralmente iterativo, e os objetivos e requisitos mudam à medida que o produto está sendo 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, essas mudanças impõem desafios que exigem mais trabalho, mais complexidade e, infelizmente, e, finalmente, mais dinheiro, tempo e trabalho duro para dar certo.

Portanto, em essência, a razão pela qual é difícil oferecer grandes projetos e estimar cronogramas e roteiros é que o desenvolvimento de software e o design especialmente funcional são campos muito complexos . Complexidade é o problema raiz.

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

Um grande projeto, tecnicamente, pode ser entregue dentro do prazo e sem falhas, desde que seja algo que tenha sido construído muitas e 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 pequenos projetos! Um editor de texto é simples ." Eu discordo de você. Os 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 escreveu o SO ou construiu o hardware.

Os projetos dos quais você está falando são grandes , semelhantes à exploração espacial. Como você sabe quanto tempo leva para desenvolver viagens inter-galácticas? Em que modelo baseamos? Você tem os conhecidos conhecidos, os desconhecidos conhecidos, os desconhecidos desconhecidos e, finalmente, os desconhecidos desconhecidos, que acontecem muito no desenvolvimento de software.

Eu acho que o problema é de expectativa. Só porque a tecnologia está lá não significa que o uso será bem-sucedido (ou sensato de usar) por um tempo. Se outras indústrias se comportassem como as indústrias de software, teríamos aspiradores à prova de buracos negros à venda até o final da década. Ou alguns "visionários" teriam recursos para construir uma base lunar e decidiram que um Starbucks realmente "completaria" a experiência dos visitantes. Eu não acho que o problema é a indústria de software, mas as expectativas colocadas sobre ele.

Embora dificilmente seja a única coisa que poderia ser mencionada, acho que vale a pena mencionar uma coisa básica. A maioria dos produtos destina-se a se adequar ao comportamento existente. Mesmo um produto que é um avanço radical (por exemplo, o carro) geralmente é construído para se ajustar ao comportamento existente, e simplesmente torna um pouco mais simples / mais fácil / mais barato / o que quer que seja. Sim, também costuma haver algum efeito colateral no comportamento existente (por exemplo, obter combustível para o carro em vez de comida para os cavalos), mas a maioria deles costuma ser um efeito colateral bastante menor.

Por outro lado, quase todos os softwares que não alteram o comportamento dos usuários (por exemplo, permitem que eles façam seu trabalho consideravelmente mais facilmente) são basicamente garantidos como uma falha completa a partir do dia 1. Pior, grandes projetos de software não apenas envolvem o comportamento dos usuários em um nível individual, mas o comportamento de grandes grupos - geralmente a totalidade da organização.

Em resumo, projetar o software em si costuma ser a parte mais fácil do trabalho. A parte difícil é redesenhar o trabalho das pessoas para elas. É difícil começar com isso; fazê-lo de uma maneira que não só funcione, mas também seja aceito é muito mais difícil ainda.

O Airbus A380 não foi um projeto bem-sucedido, como você mencionou. Por acaso, trabalho em uma empresa de CAD / CAM, e me disseram que (nós também tínhamos o projeto Airbus) atrasamos alguns anos, porque eles estavam usando uma versão diferente do software em outra empresa. Ou seja, diferentes partes estavam sendo projetadas em diferentes partes do mundo. E durante a integração, eles descobriram que todo o design não pode ser integrado, portanto, eles precisam reprojetá-lo em uma versão. Então, olhando para ele, não acho que tenha sido bem-sucedido. Se tivesse acontecido 2-3 anos antes, teria sido uma mudança de jogo para a Airbus.

Também em relação a softwares robustos, você olha para qualquer avião, carro (ABS, EPS, controle de temperatura, etc.) ou ônibus espacial. Eles têm mais de 50% de software que os executa e acredita que são muito robustos. É que estamos mais próximos do software e há muitos outros programas, então vemos mais erros neles.

Visite: http://www.globalprojectstrategy.com/lessons/case.php?id=23 e veja o sucesso do Airbus A380.

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

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

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

De fato, uma das principais razões pelas quais decidi não me tornar um engenheiro é que você passa a maior parte do tempo projetando uma melhoria de 10% em uma invenção existente, quando esse mesmo tempo pode 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. Porém, espera-se que quase todo programador modifique os projetos, os corte ou crie algo novo.

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

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

Muitas vezes, muito código depende de pessoas específicas e, se essas pessoas estão atrasadas ou não conseguem executar, o código não avança. Por outro lado, se você quiser construir um carro, pode simplesmente contratar pessoas diferentes para montar os pneus, o chassi, a bateria, o motor e assim por diante. As estruturas orientadas a objetos 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 . Os testes podem ser caros. No software, é muito tentador pular todos os testes, quando você pode 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 na verdade foi usada em megaprojetos de software). Mas com prazos apertados (que podem ser mais rigorosos de propósito), é tentador pular toda a programação e iniciar com bugs. O estilo de Joel Spolsky de "sempre consertar todos os bugs" economizará mais tempo a longo prazo, mas os indisciplinados pularão isso e fracassarão.

Pequenos projetos são melhores . Uma vez minha esposa me pediu para conseguir um emprego em uma grande empresa. Acabou argumentando que grandes empresas são más empresas ... para ela, uma grande empresa tinha muitos recursos, experiência, gerenciamento funcional de projetos e os procedimentos corretos. Para mim, uma grande empresa é um dinossauro, onde a maior parte do tempo é gasta na correção de código, no teste e na documentação.

Eu já vi projetos de TI de milhões de dólares trabalhados por menos de 10 pessoas. Mais pessoas teriam desacelerado o projeto e acrescentado 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 que realmente não foi abordada nas outras questões é que o campo do software inova a uma velocidade que ocorre apenas raramente no mundo material.

Uma razão para isso é que a evolução do software é um ciclo de feedback positivo porque o software (linguagens de programação, ferramentas de construção, IDEs) é usado para criar software. É o exemplo mais óbvio da lei de Ray Kurzweil de acelerar retornos, resultando em progresso em velocidade exponencialmente crescente. Depois de dominar uma estrutura, linguagem de programação, protocolo de comunicação, é hora de passar para a próxima.

Se os aviões fossem construídos como software, mudaríamos o material com todos os outros modelos, dobraríamos sua capacidade e velocidade a cada 18 meses, substituiríamos a tecnologia do motor para cada novo modelo por algo que acabara de ser inventado, além de acrescentar a capacidade de nadar e procurar extraterrestres. vida.

Ah, e, idealmente, ouve comandos de voz e funciona como um cinema totalmente envolvente, uma arena de paintball e uma boate com espaço escuro quando a viagem de trabalho termina. A mesma coisa! (A empresa que construiu aviões que apenas o levou de A a B caiu de barriga para baixo um ano depois do lançamento da empresa com o recurso de cinema, paintball e boate.)

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

Casos de uso

Quantos casos de uso um avião possui? A maior parte é apenas para voar de um lugar para outro. Talvez existam mais radares, controle de tráfego etc., mas o caso de uso é claro e não muito. Na engenharia de software, somos confrontados com requisitos pouco claros e com usuários que não sabem o que desejam. Diferentes usuários precisam de configurações / fluxos diferentes. Um avião pode ser personalizado conforme o usuário desejar (quero ter tv e geladeira!)?

Do utilizador

Quem opera um avião? Um piloto, um co-piloto, alguns comissários de bordo (se contados) e operadores de torre. Eles são todos profissionais e têm suas descrições de cargo claras. Os softwares são usados ​​por noobs e manequins, para não mencionar hackers e crackers, e ainda precisam ser integráveis ​​a 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 ninjas, 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. Não tenho certeza de como eles lidam com o clima nevoento, ventoso ou quente, frio e úmido, mas um avião não foi projetado para voar em diferentes níveis de gravitação (ficarei surpreso se puder voar para Marte ). Às vezes, um aplicativo deve sobreviver a diferentes plataformas, como Internet Explorer, Google Chrome , Firefox e Safari para navegador (desculpe Opera ), Windows XP / 7/8 ou Linux para SO. Sem mencionar os dispositivos móveis e diferentes resoluções e orientações.

Se você acha que outras indústrias concluem projetos sem incidentes, leia a história sobre o 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 falha grave de design que causaria o colapso de um edifício. evento de tempestade esperado a cada 16 anos.

Em outras palavras, a cada ano que o Citicorp Center permanecia, havia uma chance de 1 em 16 de que ele desabasse.

Os projetistas originais desconheciam os problemas, mas felizmente foram pegos por um aluno que estudava o prédio.

tudo parecia bem - até que, como diz LeMessurier, ele recebeu um telefonema. Segundo LeMessurier, em 1978, um estudante de arquitetura entrou em contato com ele com uma afirmação ousada sobre o prédio de LeMessurier: que o Citicorp Center poderia soprar ao vento.

Os reparos foram feitos literalmente na capa da noite, envolvendo a menor quantidade de pessoas para manter o sigilo da falha de design.

Um plano de evacuação de emergência foi preparado para o raio de 10 quarteirões ao redor do edifício.

Eles soldaram a noite toda e pararam ao amanhecer, assim como os ocupantes do prédio voltaram ao trabalho.

A história permaneceu em segredo até que o escritor Joe Morgenstern a ouviu sendo contada em uma festa e entrevistou LeMessurier. Morgenstern contou a história no The New Yorker em 1995.

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

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