Avançar para o conteúdo principal

Martin Fowler - Vale a pena desenhar bem o software ?


No seu Bliki, Martin Fowler tece considerações acerca da validade do desenho no software.

Quem desenvolve software já várias vezes foi colocado perante o problema de consumir tempo em especificações e desenho versus conseguir mostrar algo a funcionar muito rapidamente ao cliente.

Martin Fowler apresenta a sua teoria com um gráfico (a que chama pseudo gráfico por não ser derivado de algo efectivamente medido) de onde facilmente se percebe que o desenvolvimento "sem desenho" compensa nas fases iniciais de um projecto, mas que, a longo prazo irá reduzir muito a produtividade e facilidade de alteração. À linha onde se cruzam a adição de funcionalidades ao longo do tempo com e sem desenho chamou "design payoff line".

Penso que é na determinação desta linha para o nosso projecto em concreto que está o segredo para perceber se devemos ou não avançar e desenvolver ou consumir tempo a fazer um desenho cuidado do sistema.

Mais à frente Martin confirma o que eu já à muito suspeitava : trata-se de grandezas de difícil (se não impossível) medida.
Posto isto, mais uma vez concluo que se trata de uma decisão típica de gestão (neste caso de projectos) em que a experiência e bom senso do decisor será determinante na escolha da estratégia adoptada.

No seu exercício faz algo que não é comum ver na nossa indústria : apresenta as coisas em que acredita como hipótese e de seguida explica porque razão as assume como axiomas.

Decididamente um artigo a ler.

Comentários

  1. Sou um defensor de um Design cuidado. Tendo como Principal objectivo a reutilização de código em novos projectos. Defendo que cada "pedaço" de software deve cumprir um objectivo bem definido. Que poderá ser mais tarde integrado noutro projecto.

    Já dizia a minha avó:"a pressa é inimiga da perfeição".

    Nesta industria há várias "mainstream" de pensamento. Há os perfeccionistas do design, há os Speedies, há para todos os gostos. Sendo a Microsoft uma "Speedy" que lançava um novo Windows para o mercado quase anualmente, reparamos que abandonou o uso do ano nos seus produtos, porque já não tem a mesma frequência de lançamento de produtos para o mercado. Terá perdido produtividade? Sendo a Apple um exemplo de design, percebemos que não lança produtos com a mesma frequência para o mercado, mas continua a impôr-se como um produto de excelência, tendo neste momento um mercado crescente. Há no entanto uma conclusão que se tira! As empresas speedy ganham dinheiro mais cedo, mas têm dificuldade em manter a competitividade. As empresas do design, vão ganhar esse dinheiro mais tarde e provavelmente ganham um cliente para a vida. A escolha depende da filosofia de cada um.
    Há quem prefira ser o primeiro em corridas de 100 metros, há quem prefira terminar a maratona.

    ResponderEliminar

Enviar um comentário

Mensagens populares deste blogue

[Off-topic] "Novas" tendências de gestão

Afinal as novas tendências de gestão não são de agora. E as suas consequências também já são conhecidas há muito. Vejam esta carta do Senhor Vauban , Engenheiro Militar e Marechal de França, dirigida ao Senhor Losvois, Ministro da Guerra de Luís XIV, datada de 17 de Julho de 1683. "Monsenhor: ... Há alguns trabalhos nos últimos anos que não acabaram e não acabarão nunca, e tudo isso, Monsenhor, porque a confusão que causam as frequentes baixas de preços que surgem nas suas obras só servem para atrair como empreiteiros os miseráveis, malandros ou ignorantes e afugentar aqueles que são capazes de conduzir uma empresa. Digo mais, deste modo eles só atrasam e encarecem as obras consideravelmente porque essas baixas de preços e economias tão procuradas são imaginárias, dado que um empreiteiro que perde, faz o mesmo que um náufrago que se afoga, agarra-se a tudo o que pode; e agarrar-se a tudo, no ofício de empreiteiro, é não pagar aos fornecedores, pagar baixos salários, ter os piores

Conferência Europeia da Comunidade Alfresco

Já foi há quase quinze dias, mas julgo que ainda será relevante abordar a Conferência Europeia da Comunidade Alfresco, que decorreu em Barcelona no dia 22 de Abril. Com uma audiência de mais de 200 pessoas (a sala reservada estava cheia) vindas de vários pontos da Europa, este evento serviu para que muita gente desta comunidade se encontrasse pela primeira vez face a face. A Alfresco Inc. é uma empresa recente, que apostou em criar uma solução de gestão documental de topo de gama usando o modelo open-source . Considerando que a empresa, no seu terceiro ano de actividade, já atingiu o break-even , parece ter sido uma boa aposta. No arranque da conferência esteve John Powell, CEO da empresa, que falou um bocado sobre a excelente evolução da empresa e abordou a "guerra" entre o modelo de negócios proprietário e o modelo de código aberto. Exemplificou este conflito com o Microsoft SharePoint, que ele designou como "a morte da escolha", justificando o epíteto pelo facto

O que é uma POOL ?

Tenho andado a fazer implementações de mecanismos de pooling em Java 2 Enterprise Edition. Como me parece um conceito algo lato tentei a abordagem do dicionário. Alguns mostram que de facto a palavra é usada para muita coisa. A definição mais comum é "piscina". A que mais me agradou foi o que descobri na wikipedia , onde pooling é apresentada como uma técnica para guardar qualquer coisa que já não é necessária em determinado sitio (a que se chama pool ) com o objectivo de a usar quando necessário optimizando assim a utilização de recursos disponíveis. Partindo para a computação, existem vários tipos de pools: Thread Pool - Conjunto de threads livres que se vão adicionando a um fifo quando não necessárias e retirando quando se quiserem usar. Memory Pool - Conjunto de blocos de memória, todos da mesma dimensão, que se alocam inicialmente e usam à medida que necessário garantindo que o tempo de alocação de memória é constante e a fragmentação minima. Connect