gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
O negócio da programação
Contribuído por AsHeS em 05-12-01 22:25
do departamento dos-coders
News jneves escreve "Recomendo vivamente esta entrevista de Joel Spolsky. Joel foi gestor de projectos e programas na Microsoft e apressenta alguns erros normalmente cometidos em programação e o seu custo para as empresas (exemplos incluem Netscape, Novell, Borland, Lotus, WordStar, WordPerfect e Microsoft"
  • Reescrever completamente um programa.
  • Optimizar sim, mas só onde interessa.
  • Utilizar as ferramentas do nível errado para fazer um programa.
  • Acreditar na regra dos 80/20.
  • Acreditar que prima-donnas são os únicos capazes de programar num certo programa/ambiente.

Questões sobre ADSL | Linux: histórias de horror  >

 

gildot Login
Login:

Password:

Referências
  • Netscape
  • jneves
  • entrevista
  • Mais acerca News
  • Também por AsHeS
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    O Joelzinho. (Pontos:1)
    por leitao em 06-12-01 1:11 GMT (#1)
    (Utilizador Info) http://linuxfreesite.com/~nunoleitao/

        O Joel de vez em quando diz umas coisas acertadas, mas noutras coisas tem umas ideias um bocado estupidas. Por exemplo, ele defende que codigo bem escrito e' "extremely, extremely important" -- mas depois diz que e' uma ma' ideia reescrever o IIS porque "you should re-use existing code".

        Alem disso o tipo e' assim um bocado pro' pan**eiro a mais para o meu gosto...

    -- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
    Re:O Joelzinho. (Pontos:2, Interessante)
    por brandon em 06-12-01 2:11 GMT (#3)
    (Utilizador Info)
    Penso que deverias reler o artigo e com mais atenção, o Joel defende que nao se deve re-escrever código apontando várias razões perfeitamente válidas e que concordo plenamente, mas depende do contexto, ou melhor, depende do tipo da aplicação e dimensão. Em relação ao IIS, se calhar até é má ideia, experimenta ter uma empresa onde existem prazos para lançamento de produtos, em que nao queres perder dinheiro, é muito mais viável re-utilizar o código que perder anos a re-escrever, como ele ainda aponta, varios bugs existentes em versões anteriores sao reparados, e que numa versão re-escrita poderão re-aparecer. just a thought!
    Re:O Joelzinho. (Pontos:3, Informativo)
    por leitao em 06-12-01 2:20 GMT (#4)
    (Utilizador Info) http://linuxfreesite.com/~nunoleitao/

        O IIS e' talvez o software existente que mais mal causou para a imagem e qualidade da Internet -- toda a gente desde a Gartner 'a Forrester aconcelham a ou nao o usar, ou a ter muito cuidado. Se achas que isto nao e' razao...

    -- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
    Re:O Joelzinho. (Pontos:1)
    por brandon em 06-12-01 2:43 GMT (#5)
    (Utilizador Info)
    Desculpa mas estás a ver as coisas de uma perspectiva diferente, estamos a falar (o joel fala) na relação tempo/dinheiro, vale a pena perder dinheiro a pagar a programadores para re-escrever o IIS quando em meio ano com _BONS_ programadores os problemas podem ser resolvidos e novas features acrescentadas?
    O facto de ser o software A, B, ou C não está em questão, mas sim a produtividade/tempo/dinheiro.
    já vi isto em qualquer lado... (Pontos:2)
    por vaf em 06-12-01 1:44 GMT (#2)
    (Utilizador Info) http://students.fct.unl.pt/users/vaf12086/
    A primeira parte do artigo parece uma cópia quase exacta de um artigo que passou por aqui há uns meses, escrito por um jovem programador para aí de 20 anos.

    Ou o Joel se inspirou nele, ou inspiraram-se os dois no mesmo sítio...

    Igualzinho.
    Regras para monopolistas? (Pontos:1)
    por joaobranco em 06-12-01 14:34 GMT (#6)
    (Utilizador Info)
    Estas regras que são aqui apresentadas são aparentemente as adequadas para uma empresa de média/grande dimensão com um monopólio numa área de software manter ou mesmo reforçar o seu monopólio (deve ser dito que estas regras são principalmente passivas; uma única regra que podia substituir todas estas era: Não faças asneiras).

    No entanto estas regras não dão indicação sobre o que fazer (no "negócio da programação") quando se compete contra companhias maiores, com mais recursos, e a nossa própria empresa não tem os recursos e capacidades para simplesmente esperar pelas asneiras dos competidores.

    Também não me parece particularmente aplicável ao caso do software livre ou do software "open source". Ao invés das contas de merceeiro para determinar quais as áreas a suportar/desenvolver (N utilizadores a $$$ cada um versus M+N utilizadores a $ cada um) as medidas de desempenho tem de ser alteradas (uma vez que o $ é normalmente igual a 0 neste caso).

    No entanto o artigo é esclarecedor, para aqueles que tinham a ideia de que o software comercial/closed source "é mau" por incompetência dos seus desenvolvedores. Até pode ser num caso ou noutro, mas na maior parte do caso é "broken by design", o modelo de negócio é que determina quais os factores é que devem ser objecto de atenção. Os desenvolvedores serão melhores ou piores (eu até penso que a M$ tem sem dúvida dos melhores do mundo).

    JB

    Conspiração (Pontos:0)
    por Anonimo Cobarde em 06-12-01 20:41 GMT (#8)
    Microsoft always figured that it's better to let the hardware catch up with the software rather than spending time writing code for old computers owned by people who aren't buying much software any more.

    Ora aqui está a prova da teoria de associação criminosa entre a Microsoft e a Intel para compelir os utilizadores a fazer upgrades desnecessários. A maior parte das pessoas que conheço não precisa de mais do que o Word 6 em termos de funcionalidades excepto uma: a capacidade de ler ficheiros do Word 2000. Claro que há sempre quem use as mariquices, mas isso, em boa parte dos casos, serve apenas para camuflar a falta de conteúdo...

     

     

    [ Topo | FAQ | Editores | Contacto ]