Conforme o tempo vai passando pra mim ficou claro que O grande problema da nossa área está na linguagem. Sei que soa estranho em um primeiro momento, mas acredito que o fato de usarmos metáforas completamente inadequadas, normalmente vinculadas a áreas que geram produtos fisicos, como a industrial ou construção civíl.
Dado que a linguagem que usamos influencia a nossa visão do mundo, o uso de analogias ruins acaba por nos levar a erros absurdos, como por exemplo ver o processo de criação e desenvolvimento de software como uma linha de produção.
Desenvolvi uma teoria que, acredito, pode ajudar a acordar as pessoas para o problema: gostaria muito de saber a opinião de vocês.
Ainda mais, eu gostaria de saber quais metáforas vocês sugerem para que possamos acabar de uma vez por todas com analogias terríveis como a que cito no post: o da fábrica de software
Grande post, é incrível como você consegue juntar programação e conceitos filosóficos tão bem!
E realmente, o que as grandes empresas sempre procuraram foi especializar e mecanizar todos os processos o máximo possível, pra justamente ganhar em produtividade e deixar o trabalhador “manso”…
Mas em software cada caso é um caso, e é aí que acontecem os pepinos. O gestor ensina a ser robô, e passa um serviço que exige raciocínio. O desenvolvedor trabalha como foi treinado, e no final das contas paga o pato…
Bacana que tenham gostado, mas na opinião de vocês, quais metáforas poderíam entrar no lugar da que descrevo no post?
Algum tempo atrás li um livro chamado “Hackers and Painters”, do Paul Graham sobre o assunto. Nele é usada a metáfora do pintor que, assim como o desenvolvedor, vai criando seu software a partir do processo de tentativas sucessivas até que se chegue ao ponto em que tenha atingido o objetivo final. Acho que é algo mais neste caminho.
Na minha opinião, talvez alguma aproximação com o ambiente literário também é válida, porque o que fazemos, assim como na literatura, é imaterial, intelectual e não se encaixa em uma linha de montagem.
Desculpe ainda não poder participar da discussão. Li o post rapidamente e achei muito interessante. Portanto, vou ler novamente em casa e com certeza darei um feedback.
[quote=kicolobo]Bacana que tenham gostado, mas na opinião de vocês, quais metáforas poderíam entrar no lugar da que descrevo no post?
Algum tempo atrás li um livro chamado “Hackers and Painters”, do Paul Graham sobre o assunto. Nele é usada a metáfora do pintor que, assim como o desenvolvedor, vai criando seu software a partir do processo de tentativas sucessivas até que se chegue ao ponto em que tenha atingido o objetivo final. Acho que é algo mais neste caminho.
Na minha opinião, talvez alguma aproximação com o ambiente literário também é válida, porque o que fazemos, assim como na literatura, é imaterial, intelectual e não se encaixa em uma linha de montagem.[/quote]
A questão de artesanato que você também colocou no post pra mim é a que mais se encaixa com a realidade do desenvolvedor…
Tanto no artesanato como no desenvolvimento, mesmo que você o mesmo “produto” 2 vezes, eles vão ter lá suas diferenças, pois geralmente existem meios diferentes pra se chegar ao mesmo fim…
Eu por exemplo já notei isso na prática. Já fiz 3 vezes o mesmo programa para o mesmo fim(um trabalhinho de curso), e a cada vez que fazia achava um modo diferente e mais adequado à situação para chegar ao mesmo fim…
É interessante isso, e realmente não se assemelha nem de longe a processos industriais…
Olá. Parabéns pelo artigo.
Vou dar uma de advogado do diabo, mas de qualquer forma achei ele válido.
Na verdade todos esses problemas já são bem conhecidos nas empresas e por boa parte dos gerentes de TI. A questão é que não existe solução (Não existe, ou até hoje ninguém encontrou, a famosa bala de prata). Não acredito que o problema principal seja a linguagem, mas a nossa incapacidade de dar uma solução definitiva para o problema do desenvolvimento de software.
A comparação com o artesanato é interessante se a gente pensar um pouco nessa analogia.
basta observar que a produção artesanal não é mais a responsável por sustentar as necessidades do mercado. Durante um tempo ela foi suficiente, mas hoje em dia é preciso produzir em uma escala muito maior. A produção artesanal jamais daria conta de atender o mercado atual. A mesma coisa acontece com desenvolvimento de software. Desenvolver software de forma análoga à produção artesanal já não atende ao que o mercado precisa.
O P.F. é uma tentativa de atender uma necessidade do mercado. Infelizmente ele é uma grande mentira, mas é uma mentira que todo mundo aceita e que ninguém ousa questionar.
Alguns vao dizer que o problema na verdade é o modo que ele é usado, que no fim ele é só mais uma métrica, determinar o tamanho funcional do software e etc. Isso tudo é verdade. Mas ainda assim ele vai continuar sendo usado para estimar o esforço necessário para o desenvolvimento. A generalização aqui é matematicamente comprovada por metodos estatisticos. É muito complicado argumentar contra provas matemática. O problema é que todos temos a sensação de que ou tem algum erro na equação ou que então na matemática do desenvolvimento de software 1 + 1 não é 2. Ele definitivamente não é capaz de estimar o esforço necessário para produzir um software e mesmo uma generalizando matematicamente fundamentada é tão confiável quanto um chute qualquer. Mas isso é o mais próximo de alguma certeza que podemos fornecer ao mercado. Infelizmente é essa minha conclusão.
Oi immortalSoul, legal que gostou, valeu.
E muito obrigado por dar uma de advogado do diabo, porque assim a gente da uma apimentada na discussão!
sabe, ai que tá: a visão que temos de um assunto é muito influenciada pelo vocabulário que usamos quando vamos descrevê-la.
No caso, é importante lembrar que quando você usa uma metáfora baseada em artesanato, não quer dizer que vai ser artesanato, mas sim vai ter características dele.
Na minha opinião, é um passo no bom caminho sim, porque é aplicada em uma área muito próxima a nossa, a literária, com relativo grau de sucesso e, ao mesmo tempo, mantendo as características que todo negócio deve ter: prazo, custo, etc.
achei muito interessante a sua linha de raciocínio. Sinceramente, não sei se buscar novas metáforas seja o ideal, justamente porque elas podem nos levar novos erros e desentendimentos.
Se pensarmos nos tempos “pré-Engenharia de Software”, os programas, e até o hardware eram construídos sob medida para resolver problemas muito específicos (se eu não me engano, o ENIAC foi montado para cálculos de balística). Boa parte da pesquisa do meu ex-orientador por exemplo, era desenvolver soluções numéricas para equações ordinárias cujas soluções analíticas eram muito difíceis. Enfim, percebemos nestes casos que não há necessidade alguma de metáforas para descrever esse trabalho de pesquisa, muito pelo contrário. Programação e algoritmos são tidos como mais um conjunto de ferramentas com características únicas, que funcionam melhor em alguns contextos e não tão bem em outros.
Bom, é claro que desenvolver software para o mercado e para o meio acadêmico tem suas diferenças, mas elas estão muito mais relacionadas a questões como escopo, entrega de valor, prazos e etc. do que nas técnicas propriamente ditas, ou seja, no fim das contas, é tudo programação. Na minha opinião, o primeiro passo seria abandonar as metáforas de uma vez por todas e olhar para a nossa profissão como uma atividade única e começar a enumerar suas características e propriedades, assim como seus problemas. O passo seguinte, seria fazer uma análise da atividade de desenvolvimento dentro de cada contexto específico, e assim por diante.
[quote=immortalSoul]Olá. Parabéns pelo artigo.
Vou dar uma de advogado do diabo, mas de qualquer forma achei ele válido.
Na verdade todos esses problemas já são bem conhecidos nas empresas e por boa parte dos gerentes de TI. A questão é que não existe solução (Não existe, ou até hoje ninguém encontrou, a famosa bala de prata). Não acredito que o problema principal seja a linguagem, mas a nossa incapacidade de dar uma solução definitiva para o problema do desenvolvimento de software.
[/quote]
Eu acho que a solução existe sim e está aí, mas ela não é tão simples como muita gente espera. Ok, não é a bala de prata que cobrirá todos os problemas. Mas os mais comuns ela tem amenizado e alguns até eliminado. O movimento ágil é uma revolução dentro da industria do software.
O que está sendo perdido desse movimento é o porque ele existe. Há um foco enorme nas técnicas e práticas e tem se deixado de lado os princípios. E nisso essa boa parte dos gerentes de TI tem contribuído bastante para o erro. “Pra ser agil tem que ter sprint de uma ou duas semanas”. Não! Pra ser ágil tem que ter feedback rápido, uma, duas ou quatro semanas depende de uma série de coisas, como complexidade das funcionalidades, numero de equipes envolvidas, disponibilidade do cliente/analista de negócios.
Se eu tenho contato diario com meu cliente eu não preciso de uma sprint, eu posso validar cada funcionalidade no instante em que estiver pronta.
Esse é só um exemplo de como as coisas podem ser distorcidas. O mesmo acontece em várias outras práticas ditas ágeis, como pair programming, integração continua, testes, planejamento.
Há um foco grande na prática e não nos princípios. E acaba se cometendo os mesmos erros, só com nomes diferentes. Por isso para muitos as coisas continuam não dando certo.
Ponto de vista interessante. Já tinha ouvido falar da comparação entre criação de software e artesanato e não me agradou muito. Talvez seja esse mesmo o ponto. Eu não gostei muito dessa metáfora porque artesanato normalmente não é coisa que se faz em equipe e quando se envolve uma equipe essa comparação perde força.
O fato de muitos aceitarem não faz com que seja menos mentira. E talvez este seja o ponto que me leva a minha metáfora preferida. Algo que se faz em equipe e que não se estima nada e há milhares de anos tem dado certo.
Fazer software é como produzir uma peça teatral. Você tem um texto que deve ser seguido, todos o conhecem e discutem sobre ele. Todo mundo vê o todo e vendo o todo cada um faz sua parte. Há o diretor que procura manter a “big picture” da leitura que ele quer do texto. Há os atores, talentosos, que usam da sua criatividade para dar vida aos personagens sem fugir muito da visão do diretor. Há os cenógrafos, maquiadores, figurinistas que entendem o contexto pra chegarem ao resultado final.
E o melhor de tudo, o prazo já vem dado. A estréia é no dia tal e naquele dia tudo deve estar pronto. E mesmo assim a peça irá evoluir durante a temporada, a medida que os atores forem entendendo melhor a reação do público, colocando e retirando uma palavra aqui e ali.
Acho que esse é o contexto que melhor se encaixa com desenvolvimento de software. Não que sejamos artistas, embora existam as divas entre nós, mas o processo de evolução do produto é parecido com o teatro.
Grande kicoloco! Bom artigo! Meus comentários, sendo objetivo:
O cara que respondeu: “Ah, é um negócio que eu uso pra definir as propriedades dos meus beans.” ou não tem curiosidade para descobrir como as coisas funcionam realmente ou teve acesso a uma documentação tosca ou ambos. Uma coisa que eu sempre defendi é que documentação (português ou inglês) é tão ou mais importante que o código fonte (Java ou Ruby). Então seja lá onde ele leu sobre Spring, e ainda bem que não foi o seu livro, a explicação deve ter sido muito ruim.
Prática é mais importante que Teoria na minha opinião, porque com muita prática vc acaba deduzindo a teoria. Só teoria com nenhuma prática não te leva a lugar nenhum, por isso que vc deve focar mais na prática. Mas isso não quer dizer que teoria não seja importante. O cara que começa a trabalhar com Spring sem saber o que é Inversion of Control vai se enrolar.
Aí que entra o importante papel do “explicador”, do cara que escreve a documentação do framework ou um livro. Tem que explicar direito, se não ferrou.
Vou tentar (não é fácil) explicar o que é IoC em 3 linhas ao invés de usar um livro. Para quem quiser ver a prática da teoria de uma maneira bem leve e simples pode dar uma lida aqui tb: http://mentacontainer.soliveirajr.com
Sem IoC vc espalha detalhes da implementação pelo código inteiro, pois toda vez que vc faz isso:
UserDAO userDAO = new JdbcUserDAO(conn);
vc chapou (hardcodeou) que vc quer utilizar a implementação JdbcUserDAO para o seu contrato UserDAO. Vc criou uma instância de uma classe concreta na mão via new.
Com inversão de controle, ao invés de espalhar isso pelo seu código inteiro, vc usa um container de IoC (Spring, Guice, Pico, MentaContainer, etc) para CENTRALIZAR essas informação num lugar só e inverter o controle sobre as instâncias. Agora quem cria as instâncias não é vc, mas o container de IoC e injeta elas onde elas forem necessárias. Então o código acima com o MentaContainer ficaria assim:
MentaContainer container = new MentaContainer(); // esse cara vai ser compartilhado globalmente pela aplicação
container.ioc(UserDAO.class, JdbcUserDAO.class); // esse cara vai ser feito num lugar centralizado quando a aplicação for iniciada
UserDAO userDAO = container.get(UserDAO.class); // agora é assim que vc pega a instancia do seu UserDAO, ou seja, o controle foi invertido!
E aí por tabela entra Injeção de Dependência, mas aí a coisa começa a se alongar muito, acho que a explicação acima é o mínimo que o cara tem que entender e bem.
Agora vc que está escrevendo um livro sobre isso, Kico, me fala onde essa explicação pode ser melhorada e se ela contem algum erro e dá ela para o cara lá que não sabe o que é IoC ler para ver se agora ele entende.
Ai que tá: eu acredito que a metáfora da fábrica gera um efeito destruidor no profissional que está começando a sua carreira neste tipo de ambiente.
Minha visão é a de que a tentativa de se trazer a linha de montagem para o ambiente de desenvolvimento gera uma pressão tão grande por produtividade no indivíduo que ele acaba se transformando nisto que você falou: um preguiçoso. Hegel usa um termo muito bacana pra isto: “preguiça do conceito”, aquele negócio do indivíduo não querer saber o “quê” da coisa, mas somente o “como”, e rápido.
Dado que a pressão para a produção é grande, nós começamos a ver algumas coisas muito sinistras ocorrendo:
A diminuição do papel do programador, que passa a ser visto como pião (e surge o papel artificial do arquiteto, que na prática acaba sendo um programador mais experiente)
A diminuição da própria vontade de se aprofundar nos assuntos porque o ambiente é estafante.
O que observo é que neste tipo de contexto, você transforma fácil um indivíduo curioso, com vontade de aprender em um desmotivado completo que, ao dar a hora de ir pra casa, a últiam coisa que quer fazer é saber do trabalho e coisas relacionadas.
Meu medo é justamente esta alienação do ato de pensar que menciono no post. Por isto é importante novas metáforas, para que as ruins sumam, impressões cretinas como a que descrevo diminuam e, com elas, nossa área tenha um comportamento mais humano, que é o que deveria ter desde sempre, saca?
Acho que a solução tem que partir da gente. O cliente quer porque quer, o patrão cobra, então vc tem porque tem que fazer. Não adianta explicar que produzir software de qualidade requer tempo, mas que vai gerar menos custo de manutenção e blá blá blá.
Eu tenho uma política de não aceitar nada “para ontem”. Sou autônomo, mas isso quer dizer que posso me dar a esse luxo? Eu acho que não é luxo, e sim necessidade. Necessidade de recusar serviço! Explico porquê.
Esses dias um cliente meu começou a dar uma pressionada de leve. Sabe quando ele sorri e fala “então vai dar pra terminar até segunda”? Eu tive que mudar o tom, lembrá-lo do prazo que eu pedi para fazer o serviço e disse que se ele contasse mesmo com isso, era melhor esquecer. Apenas 2 semanas, programa pequeno mas que deu um certo trabalho - imagine integrar um sistema Clipper legado com uma aplicação de coleta de dados para ser acessada em campo através de iPad. Isso cai naquilo que o Kico falou no blog dele: Qualidade requer tempo para se obter o conhecimento a respeito da essência do problema, ou seja, para entender com o quê estamos lidando.
O cliente ficou meio sem graça, mas eu tinha achado a atitude dele tão abusada (e isso é muito comum) que eu dei a cara a tapa mesmo, arrisquei perder o serviço.
Existe uma armadilha nas relações humanas, e essa armadilha é mais forte na questão do trabalho:
quem tem o $$$$ decide
quem quer ganhar o $$$$ aceita as condições que o outro impõe, sob pena de perder serviço, ficar de filme queimado, ser demitido no caso de não-autônomos
Nos últimos tempos venho me questionando: eu estou precisando do $$$ do cliente X? Por “precisar” entenda-se não estar passando necessidade, mas sim no sentido de que todos precisamos de grana e é desenvolvendo software que eu ganho a vida.
Se os desenvolvedores resolvessem recusar fazer milagres, aí sim viraríamos o jogo. Uma quantidade assombrosa de serviços seriam recusados pelos autônomos, e outra massa de gente iria pedir as contas/ser demitida. Já pensou faltar mão de obra para fazer software? Agora juntando as peças: acredito que é dessa forma que eles (os que nos solicitam os serviços) ouvirão o que nós falamos. Quando nós fizermos falta, deixaremos de ser “fábrica de software” e poderemos de verdade colocar para o mundo todos os argumentos que foram discutidos neste tópico.
Pode parecer um tanto radical, mas a nossa área é extremamente incompreendida. Da mesma forma que eu preciso de grana, eles precisam do meu serviço. Quem quer muito ganhar o bem do outro é o mais frágil da relação; quem se dispõe a recusar o negócio é o lado mais forte.
[quote=YvGa][quote=immortalSoul]Olá. Parabéns pelo artigo.
Vou dar uma de advogado do diabo, mas de qualquer forma achei ele válido.
Na verdade todos esses problemas já são bem conhecidos nas empresas e por boa parte dos gerentes de TI. A questão é que não existe solução (Não existe, ou até hoje ninguém encontrou, a famosa bala de prata). Não acredito que o problema principal seja a linguagem, mas a nossa incapacidade de dar uma solução definitiva para o problema do desenvolvimento de software.
[/quote]
Eu acho que a solução existe sim e está aí, mas ela não é tão simples como muita gente espera. Ok, não é a bala de prata que cobrirá todos os problemas. Mas os mais comuns ela tem amenizado e alguns até eliminado. O movimento ágil é uma revolução dentro da industria do software.
O que está sendo perdido desse movimento é o porque ele existe. Há um foco enorme nas técnicas e práticas e tem se deixado de lado os princípios. E nisso essa boa parte dos gerentes de TI tem contribuído bastante para o erro. “Pra ser agil tem que ter sprint de uma ou duas semanas”. Não! Pra ser ágil tem que ter feedback rápido, uma, duas ou quatro semanas depende de uma série de coisas, como complexidade das funcionalidades, numero de equipes envolvidas, disponibilidade do cliente/analista de negócios.
Se eu tenho contato diario com meu cliente eu não preciso de uma sprint, eu posso validar cada funcionalidade no instante em que estiver pronta.
Esse é só um exemplo de como as coisas podem ser distorcidas. O mesmo acontece em várias outras práticas ditas ágeis, como pair programming, integração continua, testes, planejamento.
Há um foco grande na prática e não nos princípios. E acaba se cometendo os mesmos erros, só com nomes diferentes. Por isso para muitos as coisas continuam não dando certo.
Ponto de vista interessante. Já tinha ouvido falar da comparação entre criação de software e artesanato e não me agradou muito. Talvez seja esse mesmo o ponto. Eu não gostei muito dessa metáfora porque artesanato normalmente não é coisa que se faz em equipe e quando se envolve uma equipe essa comparação perde força.
O fato de muitos aceitarem não faz com que seja menos mentira. E talvez este seja o ponto que me leva a minha metáfora preferida. Algo que se faz em equipe e que não se estima nada e há milhares de anos tem dado certo.
Fazer software é como produzir uma peça teatral. Você tem um texto que deve ser seguido, todos o conhecem e discutem sobre ele. Todo mundo vê o todo e vendo o todo cada um faz sua parte. Há o diretor que procura manter a “big picture” da leitura que ele quer do texto. Há os atores, talentosos, que usam da sua criatividade para dar vida aos personagens sem fugir muito da visão do diretor. Há os cenógrafos, maquiadores, figurinistas que entendem o contexto pra chegarem ao resultado final.
E o melhor de tudo, o prazo já vem dado. A estréia é no dia tal e naquele dia tudo deve estar pronto. E mesmo assim a peça irá evoluir durante a temporada, a medida que os atores forem entendendo melhor a reação do público, colocando e retirando uma palavra aqui e ali.
Acho que esse é o contexto que melhor se encaixa com desenvolvimento de software. Não que sejamos artistas, embora existam as divas entre nós, mas o processo de evolução do produto é parecido com o teatro.[/quote]
Em primeiro lugar, gostei da analogia com o teatro. A principio acho que poderia ser observada pra começar a pensar em uma solução para o problema causado pela linguagem, conforme alertado pelo KicoLobo.
Quanto ao movimento agil, conheço de ouvir falar (apesar de não ter tido a oportunidade de trabalhar com ele) e concordo que ele é o melhor que temos para grande parte do desenvolvimento de software.
Mas lembre-se que o que falei é que não temos a solução definitiva. Infelizmente existe uma série de barreiras que impende um alcance mais amplo deste movimento.
Creio que o maior problema é o fato das empresas não aceitarem que o desenvolvimento de softawre não é uma atividade ‘deterministica’. Boa parte do mercado não nestá preparado para aceitar isso e não sei se um dia vai estar.
[quote=MarkKnopfler]
Pode parecer um tanto radical, mas a nossa área é extremamente incompreendida. Da mesma forma que eu preciso de grana, eles precisam do meu serviço. Quem quer muito ganhar o bem do outro é o mais frágil da relação; quem se dispõe a recusar o negócio é o lado mais forte.[/quote]
Concordo plenamente com voce. É uma visao dificil de por em pratica, principalmente pra quem é pequeno, mas é necessaria.
Mas a de se ter cuidado com essa frase do kiko:
Sim, qualidade requer tempo, mas deve se tomar cuidado com o ficar procrastinando em cima do papel e não fazer nada com a desculpa da busca da qualidade. Só se entende o problema de fato com algo concreto para ser demonstrado, não com discussões vagas, desenhos, reuniões. Um protótipo de tela feito em 10 minutos vale mais do que horas de reunião. Uma implementação rápida, de uma hora, de uma funcionalidade chave para ser discutida com o cliente vale muito mais do que toneladas de requisitos assinados e acordados.
Eu não tenho essa aversão a palavra produtividade como o kiko, eu tenho aversão a forma como ela é medida.
Esse fazer de qualquer jeito não traz produtividade, na verdade diminui. Eu sempre digo a tal “fase de manutenção”, quando haverá o ganho, começa bem antes do sistema em produção. Ou seja, tudo que for feito de qualquer jeito cobrará seu preço bem antes do que muita gente julga. E atrasará, ao invés, de acelerar a entrega do produto.
Os melhores programadores que eu conheci eram os mais produtivos. Eles invariavelmente eram mais rápidos e produziam com mais qualidade que os outros. Porque sabiam escrever código de qualidade que não os atrasava.
Resumindo: sempre que me falam em produtividade eu pergunto: Como você mede isso? Exatamente?
Sem chance do mercado aceitar isso. Mas talvez o melhor caminho seja mesmo o que o rmendes falou. Vamos esquecer as metáforas e construir nossa própria forma de trabalhar.
eu não tenho aversão à produtividade: tenho aversão à visão aplicada sobre o assunto. (seria contra-senso ter aversão a uma qualidade)
Com relação à criação de novas metáforas ou cair na prática, acho interessante partir pra primeira.
Tudo bem que a teoria surge a partir da prática e blá blá blá, mas ao mesmo tempo, a imagem que passamos aos nossos clientes de nós mesmos é profundamente influenciada pelos termos que usamos para descrever nosso trabalho, entende?
O interessante é que a questão da linguagem é na realidade epistemológica, está diretamente relacionada à nossa maneira como percebemos o mundo e, consequêntemente, interagimos com ele.
Sendo assim, é um ponto básico que está sendo subvertido e precisa ser corrigido o quanto antes, de preferência a partir de agora enquanto nossa área é nova e ainda dá tempo de evitar a cristalização total destas metáforas ruins que mencionei acima.
[quote=YvGa]
Fazer software é como produzir uma peça teatral. Você tem um texto que deve ser seguido, todos o conhecem e discutem sobre ele. Todo mundo vê o todo e vendo o todo cada um faz sua parte. Há o diretor que procura manter a “big picture” da leitura que ele quer do texto. Há os atores, talentosos, que usam da sua criatividade para dar vida aos personagens sem fugir muito da visão do diretor. Há os cenógrafos, maquiadores, figurinistas que entendem o contexto pra chegarem ao resultado final.
E o melhor de tudo, o prazo já vem dado. A estréia é no dia tal e naquele dia tudo deve estar pronto. E mesmo assim a peça irá evoluir durante a temporada, a medida que os atores forem entendendo melhor a reação do público, colocando e retirando uma palavra aqui e ali.
Acho que esse é o contexto que melhor se encaixa com desenvolvimento de software. Não que sejamos artistas, embora existam as divas entre nós, mas o processo de evolução do produto é parecido com o teatro.[/quote]
Dos projetos de software que participei, o fato de que a “peça vai ao ar” porque chegou o dia da “estréia” e não porque o produto ficou pronto, é a principal causa de equipe frustrada e usuários insatisfeitos.
Ainda assim acredito que a analogia entre teatro e artesanato é apta porque salienta um problema real: a falta de especificações detalhadas sobre o produto, o que ele deve fazer e principalmente, o que significa estar pronto.
Em áreas mais tradicionais como construção civil todos sabem quando um prédio está pronto porque ele se parece e funciona igual o protótipo diz que deve parecer e funcionar, e não porque estorou o prazo do projeto.
Um ponto interessante, mas o problema é que tempo é dinheiro, não? Um projeto que atrasa geralmente fica mais caro, as pessoas ficam mais ansiosas, a pressão aumenta, etc.
A qualidade de um projeto não é influenciada pelo tempo que ele tomou para ser desenvolvido. Mas isso não quer dizer que tempo não tem custo.
Dois projetos com a mesma qualidade: um feito em em 3 meses e outro em um ano. O que foi feito em 3 meses tem mais valor eu diria.
Bom artigo! Meus comentários, sendo objetivo: