Existe uma moda de falar em sistema pequenos. “Posso fazer xxxxx ? é para um sistema pequeno.” , ” se eu fizer xxxxx tudo bem, certo? é apenas um sistema pequeno” – todos já ouvimos isto e até alguns já podem ter dito. Normalmente xxxxx é alguma gambiarra.Do tipo, posso fazer meu sistema apenas com métodos estáticos ? é um sistema pequeno.
Para mim isto é uma falácia do pensamento. Não existe sistema pequeno. O sistema pode nascer pequeno – modesto em funcionalidades – mas ele tende a evoluir. Mais cedo ou mais tarde esse sistema irá precisa de manutenção (leia-se corrigir algum problema ou aumentar as suas funcionalidades). Com a manutenção o sistema irá crescer.
Esta lógica leva-me a crer que quando alguem diz “sistema pequeno” está pensando em “sistema fast-food para enganar trouxa”, ou seja, “vou fazer esta porcaria, vender por uma nota e ganhar uma nota. Se o cara me processar depois, eu não vou estar mais aqui”. Este tipo de pensamento é triste. Mostra que ha muitos mercenários por ai que não têm qualquer honra no trabalho que fazem e tudo o que querem é dinheiro. Software, infelizmente, não dá dinheiro. Boas ideias dão dinheiro. Boas execuções dão dinheiro.
Será então que quem pensa em sistemas pequenos tem a vista curta ? Que não pensa a longo prazo ? Este tipo pensamento pode-nos levar por um longo caminho de asneiras. Por exemplo, se o sistema é “pequeno” porquê construir camadas ? porque isolar componentes ? porquê escolher frameworks e tecnologias que trabalham bem juntas? porquê seguir boas práticas ? aliás, porquê aprender boas práticas ? porque investir aprendendo Orientação a Objetos ? porquê levantar requisitos ? porquê sequer fazer direito quando pode fazer rápido ?
Uma outra face desta moeda furada é o comum “vamos fazer só assim, e depois a gente vê como faz o resto”. Basicamente, traduzindo, significa “vamos fazer um sistema ‘pequeno’ e depois o aumentaremos”. Mas o que é pequeno aqui é a visão. Visão curta. Pensar grande corta tempo e custos porque se pensa em todas a partes. Não ha imprevisto nem surpresas. Podemos componentizar as coisas e deixar alguns componentes com implementações mais simples do que gostaríamos – mais simples, não mais “pequena”.
Aliado ao tamanho “pequeno” temos o intervalo de tempo “pequeno”. Frases como “vamos fazer um sistema pequeno para vender logo” ; leia-se : “vamos produzir um porcaria qualquer só para por no mercado sem pensar como isso afeta a nossa imagem , aumenta o risco e produz custos não estimados e altos”.
Os Romanos pensaram grande quando disseram “vamos conquistar o mundo”. E para isso criaram um estrutura social completa, infraestrutura. Infraestrutura sem a qual não seria possível conquistar nada nem ninguém. Criaram estratégias pontuais para alcançarem o objetivo maior.
Não pense pequeno. Aprenda a pensar grande. Aprenda a dividir para conquistar. Para isso nunca abra mão da qualidade do software que produz. É o seu nome, a sua dignidade, a sua honra que está nisso. Eleve a qualidade do código/software que lhe chega em mãos. Não tenha medo se defender a bandeira da qualidade. Se alguem não gostar, tenha a certeza que são eles que estão errados.
E sei que temos que comer e para isso precisamos trabalhar. E para trabalhar precisamos engolir alguns sapos de vez em quando. Mas existe um limite moral até onde você pode ir. A partir daí é trabalho intelectual forçado, é escravatura intelectual, é prostituição intelectual.
Mercenários pensam pequeno e ganham dinheiro, mas são infelizes e mal vistos pela sua falta de moral. Ninguém confia neles. Artistas pensam grande e são normalmente felizes e as pessoas tendem a confiar neles. Tudo bem que ha artistas que nada ganham e outros que ganham muito. Isso depende do talento de cada um. Não apenas do talento artístico como do comercial, interpessoal, etc..
Embora possa parecer que pensar pequeno pode ser uma vantagem a curto prazo, nunca é uma vantagem a longo prazo. E sendo que sistemas sempre duram além da sua vida útil, o longo prazo mal planejado tende a ser um problema.
Você pode pensar grande e dar passos simples , um de cada vez e chegar no que pensou. Mas ao pensar pequeno por muito que corra nunca vai chegar onde deveria. Isso porque você não sabe onde deveria chegar. Porque não pensou nisso antes ?
Sérgio Taborda's Weblog 
Fala Sergio, seu post veio na hora certa.. a duas semanas comecei a desenvolver um sistema pequeno para a empresa em que trabalhava, as dicas dos meus ex-colegas foram : “Deixa assim mesmo, qualquer coisa depois mudamos..”, “è muito pequeno para criar camadas”,”não precisa usar MVC, usa tal tecnologia”.. Eu fiquei pensando se eu estava com alguma sindrome de “Boas práticas” mas depois do seu post acho que não. Estou indo trabalhar em uma nova empresa, a idéia que tive dessa empresa é que lá a ideologia de sistemas pequenos não toma conta.
Grande abraço!
Concordo que boas práticas de desenvolvimento precisam ser aplicadas a todos os sistemas, independentemente do seu tamanho. Tem que estar no sangue… Mas temos que levar em consideração o fato de usarmos tecnologias totalmente novas em sistemas “pequenos” que deveriam ser entregues pra ontem. Precisamos ter em mente se o tempo para aprendermos sobre a nova tecnologia + tempo real de desenvolvimento, será maior do que seria o tempo para desenvolver o sistema em uma tecnologia já conhecida. Não sendo esse caso, não há problemas !! abração !!
Taborda,
O que penso é que na linha de produção não gerenciamos somos gerenciados, e em outra situação pouco se investi em gerencia de projetos ou isso é para grandes corporações que vendem soluções em qualidade, mas quem emprega qualidade cai no mesmo vazio, equipes são de dificil sincronismo, motivo disso nem todos tem o mesmo conhecimento intelectual ou experiencia.Qualidade passou a ser venda de software final , na produção o sistema tem que esta no ar custe o que custar. Em uma experiência que tive com desenvolvimento os reflexos de panes eram vistas no CVS, mas a responsabilidade era na qualidade do codigo , mas como acertar algoritmos de varias estações sabendo que responsabilidade tal rotina ou comportamento de milhares de codigos vão ou estarão alinhado até de projetos que são legados e também estão em migração.A separação de responsabilidades estou vendo que esta a cargo de softwares que façam o serviço que humanos não sabem fazer , que é exatamente qualidade em codigo.
abraçosss
Para obter qualidade no código há que seguir boas práticas em vários níveis. Há que treinar as pessoas e há que responsabilizá-las. A qualidade não se obtém magicamente. Tem que existir um líder de equipe (um cara que sabe o que está fazendo) que impõe a qualidade.
Em relação ao gerenciamento o Scrum é uma ótima forma de resolver o problema. Isto porque se quisermos podemos despedir o gerente.
Sendo que o gerente é o elo mais fraco do processo isso elimina muitos problemas. Coloque um arquiteto ou alguem capacitado no mesmo nível como líder da equipe que é responsável por tudo o que é técnico no projeto (líder técnico) e utilize scrum para gerenciar. A separação de responsabilidades sim´e algo que os humanos não sabem fazer é por isso que o Scrum e todas a metologia ágeis assentam em um pilar comum : responsabilidade partilhada. A responsabilidade é de todos. Se A escreveu um código ruim e B viu isso, B vai lá e resolve. Não fica à espera. Porque no fim, se der merda tanto A quanto B são responsáveis em partes iguais.
É por isto que scrum e xp funcionam, porque todos partilham a responsabilidade. Isto é natural e leva as pessoas a se ajudarem, em vez de terarem ferrar o próximo.
O pior é que esse pensamento muitas vezes vem de “cima”,pois tenho um coordenador que sempre nos diz : “ponha um if ai e entrega para o cliente, temos que tirar isso do nosso colo”.
Esse tipo de pensamento me frusta muito.
É realmente frustrante. O pior é que só ha duas alternativas : ficar com o lugar dele ou procurar outro lugar.