Performance x Pessoas: Compensando Perdas com Infra-Estrutura

Estava conversando com uns amigos e chegamos a uma dúvida bem interessante: por que as empresas acham normal gastar fortunas em infra-estrutura(CPUs, cores, memória, máquinas, RAC, cluster, cache, replicação) e não acham sequer razoável gastar esse investimento para migar para uma plataforma mais eficiente?.

A empresa típica hoje tem na sua linha de frente programadores..uhm… “não-ótimos” para o serviço. Estes programadores geralmente são “adquiridos” por um valor baixo e possuem como característica básica o “trabalho não otimizado” e err… a “rápida depreciação e eventual substituição da mão de obra”.

Ok, sem mais eufemismos porque este blog não se gaba por ser enterprisey: contratam pessoas ruins que ficam pulando de empresa em empresa porque podem pagar pouco (comparado ao preço de um desenvolvedor de verdade) para elas.

E como isso dá certo? Bom, macacos digitando infinitamente não reproduzem a obra de Shakespeare, mas eu garanto que se eles martelarem um teclado por algum tempo eles escrevem boa parte das aplicações Java EE ou .Net criadas hoje em dia. Desenvolvedores ruins sempre existiram mas desde o advento de ferramentas como Visual Basic e Delphi, além de plataformas gerenciadas como Java e .Net se tornou viável contratar um bando deles de largá-los amrtelando teclados sendor egidos por gerentes de pojeto que se gabam de ter sua ‘arte’ surgida na Roma antiga e acabam aplicando práticas de gestão desta época.

Vamos e venhamos: as aplicações criadas na maioria das empresas são estupidamente simples, qualquer zé mané faz. E também na maioria das aplicações basta se comprar um servidor de R$2.000,00 e qualquer aplicação construída por uma menina de 3 anos roda bem que é uma beleza. Claro que a aplicação precisa escalar, ou precisamos ainda já começar pensando grande (pense numa empresa de telecomunicações), se nosso software foi construído por macacos de Shakespeare como podemos fazê-la escalar?

Com hardware.
Máquina. Memória. CPU. Banco de Dados replicado. Particionado. Cache. Quemt em aço e silício dispensa cérebros.

E porque é tão inpensável contratar bons profissionais (que, segundo estudos, podem substituir 10 ou mais code monkeys) e dar a eles uma ferramenta eficaz e eficiente como Ruby/Rails, JRuby/Jython/IronPython/Groovy, PHP, Seaside ou Python?

Por definição uma plataforma de mais alto nível é menos performática mas quase sempre podemos vencer isso na infra-estrutura.

Que tal parar de gastar numa aplicação ruim, que vai dar problema de manutenção frequente, numa plataforma complexa por algo que tem o mesmo custo total, foi feito por 1/10 das pessoas numa plataforma simples?

Update: Faltou a conclusão: por isso que uma empresa de centenas de pessoas e milhares de verdinhas se mata para imitar o que quatro garotos que vivemd e mesada criam nos fins de semana (e não conseguem nem chegar perto!).
Ok, não é por isso, mas é um dos motivos.

7 Responses to “Performance x Pessoas: Compensando Perdas com Infra-Estrutura”

  1. Marcos Silva Pereira Says:

    Porque as empresas:
    1. Não pensam a longo prazo
    2. Não valorizam as pessoas como deveriam
    3. Pensam em TI como commodity e não como utility
    4. Têm visão errada sobre os desenvolvedores (bando de nerds e seus computadores)

    E porque algumas são simplesmente burras mesmo e ponto.

    valeuz…

  2. Leandro Ribeiro Says:

    Pagar um ‘pseudo programador’ para fazer pseudo aplicações que poderam funcionar ou não, mais tarde gastar muito dinheiro para transformar essas pseudo-qualquercoisa em blocos consisos de software.
    Porém prefere-se comprar três servidores … muitos da área de TI usam isso, se uma aplicação está ‘lenta’ (so many problems) é culpa da plataforma de hardware.

    A cada dia um ‘post’ melhor…
    [Esse é o dilema]

  3. Christiano Milfont Says:

    O desenvolvimento de software tenta seguir os modelos de administração onde a mão-de-obra é um centro de custo.
    A analogia com engenharia civil também acaba contribuindo para a equação, o desenvolvedor acaba sendo um peão ou um arquiteto.
    No meu entender o software é uma arte, e um artista não tem prazo e sim inspiração!
    Um software são idéias materializadas em bits, resoluções e equações executadas por máquinas, não há outro paralelo igual ao software e por ser especial sua fabricação é especial, cara e única como qualquer arte.
    O google tem se destacado por valorizar o desenvolvedor como um artista, com todos os mimos que ele necessita.
    Enquanto as empresas considerarem o desenvolvedor como insumo de um produto e software um produto vamos continuar assim.

  4. Daniel Quirino Says:

    Vou imprimir este post e largar na mesa de algumas pessoas na EDS. Vamos ver qual vai ser a reação :D

  5. Fragmental » 3 Letrinhas Says:

    […] empresas se aproveitam do fato de que qualquer macaco consegue criar um programa de computador e que todo mundo precisa de programas de computador, ou pelo menos pensa que precisa. O modelo de […]

  6. Flamer Says:

    Bom, eu caí no site por acaso, procurando sobre lisp no Google. Achei o post interessante, inclusive o link para o Lema de Borel-Cantelli na Wikipedia. Só que tem um probleminha. Os macados *vão* terminar por digitar as obras completas de Shakespeare, e isso ocorre com probabilidade 1.

  7. anselmo alves - Um blog sobre computação » Blog Archive » Aplicações web nativas - por que não? Says:

    […] solução para problemas de performance. Estas questões precisam ser primariamente endereçadas a melhorias arquiteturais e infraestruturais desenhadas para cada aplicação particular. Apenas questiono o fato de nós desenvolvedores, na […]

Leave a Reply