A empresa de desenvolvimento de software mais poderosa do mundo não conseguiu entregar o seu produto dentro do prazo previsto. O Windows Vista tinha entrega prevista para março de 2006, mas acabou sendo entregue 10 meses depois. Os principais motivos foram problemas com a sua arquitetura e gerência de software. Estes problemas vêm, há anos, sendo descritos na literatura da Engenharia de Software.
O código do Vista cresceu para o espantoso número de aproximadamente 50 milhões de linhas de código fonte e sua arquitetura tornou-se um caótico “spaghetti”. Uma arquitetura spaguetti é aquela na qual o código torna-se tão dependente de outras partes que o acompanhamento do fluxo de controle possui tantas idas e vindas de uma parte para a outra que fica praticamente impossível entendê-lo. Além disso, qualquer pequeno ajuste em uma pequena parte do sistema é imprevisível e pode desestabilizar o código, levando-o a um comportamento defeituoso.
Os problemas e causas do código spaguetti foram diagnosticados no final da década de 60 e durante os anos 70 diversas estratégias foram apontadas para evitá-lo. Dentre elas estão as técnicas de programação estruturada, o princípio da informação escondida e a modularização. Para solucionar o problema do código spaguetti, a Microsoft jogou fora o código trabalhado e voltar ao código de base do servidor do Windows 2000/XP que possuía bem menos defeitos. A equipe foi orientada a construir módulos a partir desta base.
Outro fator fundamental foi que a equipe cresceu para a enorme quantidade de 4000 programadores e 4000 testadores. Este número cresceu devido a um fator condenado há vários anos na engenharia de software no clássico livro “The Mythical Man-Month” de Frederick Brooks, engenheiro de software da IBM, responsável pelo sistema operacional OS-360, na segunda metade da década de 60 (Brooks, 1975). Em seu livro de 1975, Fred Brooks aponta que quando uma empresa está com prazos apertados, o aumento no número de pessoas na equipe de desenvolvimento, o que teoricamente poderia reduzir os prazos de entrega, não necessariamente causa o aumento de produtividade. Quando o número de pessoas em uma equipe aumenta, os canais de comunicação aumentam de forma exponencial e a gerência do projeto torna-se extremamente complexa. Quanto mais gente, mais atrasos.
A Microsoft tornou-se a mais poderosa indústria de software por uma boa estratégia política e de marketing – algumas das quais levou a empresa a responder a processos judiciais – e também pela produção de produtos de qualidade. Produtos como o Office são um sucesso pela forma como foram projetados e como o seu processo foi conduzido. A Microsoft conduziu este processo numa estratégia conhecido como “sincronizar-e-estabilizar”(Cusumano, 1997). Neste processo são definidos marcos a partir da divisão do produto em pequenas partes. As partes são entregues a times pequenos de jovens programadores, recém saídos das universidades, que trabalham no estilo “hacking” em salas que lembram alojamentos universitários, movidos a junk food (Coupland, 1995). No processo de sincronizar e estabilizar da Microsoft, builds (código compilado) são produzidos diariamente e em reuniões de sincronização são testados e corrigidos de forma a produzir versões estáveis. Esta estratégia, na década de 90, era bastante diferente daquelas conduzidas pela IBM nas quais milhares de engenheiros eram recrutados para o desenvolvimento de seus produtos de software. Na Microsoft, a equipe que desenvolveu o NT tinha algo em torno de 400 pessoas, na época a maior da empresa.
No entanto, mesmo com o seu bem sucedido processo de software de “sincronizar e estabilizar”, a Microsoft teve bastante dificuldade de realizar sincronização diária com uma equipe de 8000 pessoas e consertar defeitos em um código mal arquitetado com 50 milhões de linhas de código.
A versão beta do Windows Vista ficou pronta em agosto de 2005. Um ano e meio de foi reservado para testes e em janeiro de 2007 foi colocada à venda no mercado mundial. O projeto total levou 6 anos e consumiu 2 bilhões de dólares de investimento em programação e testes (Cusumano, 2006).
O que ocorreu com o desenvolvimento do Vista mostra que mesmo as poderosas empresas ainda cometem erros básicos de engenharia de software. O Windows 95 tinha cerca de 11 milhões de linhas de código e foi construído por um time de 200 pessoas. O Windows 98 tinha cerca de 15 milhões de código e o Windows XP cresceu para 25 milhões, construídos por uma equipe de 2000 pessoas. Terá a próxima versão do sistema operacional da Microsoft a astronômica quantidade de 100 milhões de linhas de código fonte? A empresa será capaz de desenhar uma arquitetura para este código e de gerenciar um time com 16 mil pessoas?
Referências
Brooks, Jr., F.P. The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Reading, MA: Addison-Wesley, 1995, 322 pages.
Brechner, Eric. "Journey of Enlightenment: The Evolution of Development at Microsoft" - ICSE’05 May 15–21, 2005, St. Louis, Missouri, USA.
Coupland, D. Microserfs. HarperCollins, 1995.
Cusumano, M & Selby, R. How Microsoft Builds Software - Communications of the ACM, jun1997, vol. 40, no. 6
Cusumano, M. ""What road ahead for Microsoft and Windows? Communications of the ACM archive, Volume 49 , Issue 7 (July 2006)
O código do Vista cresceu para o espantoso número de aproximadamente 50 milhões de linhas de código fonte e sua arquitetura tornou-se um caótico “spaghetti”. Uma arquitetura spaguetti é aquela na qual o código torna-se tão dependente de outras partes que o acompanhamento do fluxo de controle possui tantas idas e vindas de uma parte para a outra que fica praticamente impossível entendê-lo. Além disso, qualquer pequeno ajuste em uma pequena parte do sistema é imprevisível e pode desestabilizar o código, levando-o a um comportamento defeituoso.
Os problemas e causas do código spaguetti foram diagnosticados no final da década de 60 e durante os anos 70 diversas estratégias foram apontadas para evitá-lo. Dentre elas estão as técnicas de programação estruturada, o princípio da informação escondida e a modularização. Para solucionar o problema do código spaguetti, a Microsoft jogou fora o código trabalhado e voltar ao código de base do servidor do Windows 2000/XP que possuía bem menos defeitos. A equipe foi orientada a construir módulos a partir desta base.
Outro fator fundamental foi que a equipe cresceu para a enorme quantidade de 4000 programadores e 4000 testadores. Este número cresceu devido a um fator condenado há vários anos na engenharia de software no clássico livro “The Mythical Man-Month” de Frederick Brooks, engenheiro de software da IBM, responsável pelo sistema operacional OS-360, na segunda metade da década de 60 (Brooks, 1975). Em seu livro de 1975, Fred Brooks aponta que quando uma empresa está com prazos apertados, o aumento no número de pessoas na equipe de desenvolvimento, o que teoricamente poderia reduzir os prazos de entrega, não necessariamente causa o aumento de produtividade. Quando o número de pessoas em uma equipe aumenta, os canais de comunicação aumentam de forma exponencial e a gerência do projeto torna-se extremamente complexa. Quanto mais gente, mais atrasos.
A Microsoft tornou-se a mais poderosa indústria de software por uma boa estratégia política e de marketing – algumas das quais levou a empresa a responder a processos judiciais – e também pela produção de produtos de qualidade. Produtos como o Office são um sucesso pela forma como foram projetados e como o seu processo foi conduzido. A Microsoft conduziu este processo numa estratégia conhecido como “sincronizar-e-estabilizar”(Cusumano, 1997). Neste processo são definidos marcos a partir da divisão do produto em pequenas partes. As partes são entregues a times pequenos de jovens programadores, recém saídos das universidades, que trabalham no estilo “hacking” em salas que lembram alojamentos universitários, movidos a junk food (Coupland, 1995). No processo de sincronizar e estabilizar da Microsoft, builds (código compilado) são produzidos diariamente e em reuniões de sincronização são testados e corrigidos de forma a produzir versões estáveis. Esta estratégia, na década de 90, era bastante diferente daquelas conduzidas pela IBM nas quais milhares de engenheiros eram recrutados para o desenvolvimento de seus produtos de software. Na Microsoft, a equipe que desenvolveu o NT tinha algo em torno de 400 pessoas, na época a maior da empresa.
No entanto, mesmo com o seu bem sucedido processo de software de “sincronizar e estabilizar”, a Microsoft teve bastante dificuldade de realizar sincronização diária com uma equipe de 8000 pessoas e consertar defeitos em um código mal arquitetado com 50 milhões de linhas de código.
A versão beta do Windows Vista ficou pronta em agosto de 2005. Um ano e meio de foi reservado para testes e em janeiro de 2007 foi colocada à venda no mercado mundial. O projeto total levou 6 anos e consumiu 2 bilhões de dólares de investimento em programação e testes (Cusumano, 2006).
O que ocorreu com o desenvolvimento do Vista mostra que mesmo as poderosas empresas ainda cometem erros básicos de engenharia de software. O Windows 95 tinha cerca de 11 milhões de linhas de código e foi construído por um time de 200 pessoas. O Windows 98 tinha cerca de 15 milhões de código e o Windows XP cresceu para 25 milhões, construídos por uma equipe de 2000 pessoas. Terá a próxima versão do sistema operacional da Microsoft a astronômica quantidade de 100 milhões de linhas de código fonte? A empresa será capaz de desenhar uma arquitetura para este código e de gerenciar um time com 16 mil pessoas?
Referências
Brooks, Jr., F.P. The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Reading, MA: Addison-Wesley, 1995, 322 pages.
Brechner, Eric. "Journey of Enlightenment: The Evolution of Development at Microsoft" - ICSE’05 May 15–21, 2005, St. Louis, Missouri, USA.
Coupland, D. Microserfs. HarperCollins, 1995.
Cusumano, M & Selby, R. How Microsoft Builds Software - Communications of the ACM, jun1997, vol. 40, no. 6
Cusumano, M. ""What road ahead for Microsoft and Windows? Communications of the ACM archive, Volume 49 , Issue 7 (July 2006)
Comentários
Abraços
Bruno
ée, o que precisa ai, um gerenciamento muito grande mesmo.. ;x
vai da parte dos analista de sistemas, em encaminhar a produção toda engembrada, para não ocorrer como o queridinho sumo vista.. ;D