Keep it Simple

De uns tempos pra cá, desde que começamos a utilizar o Scrum na Globo.com, venho a cada dia reforçando minha idéia de que quanto mais simples, melhor. Muitas vezes, principalmente nós, engenheiros, queremos implementar as soluções mais mirabolantes para problemas muitas vezes não tão complexos, pela simples capacidade criativa que existe em nós. No caso específico de desenvolvimento de software, as vezes ficamos horas e horas tentando otimizar cada linha, cada processo, literalmente escovando bits, para ganhar um mínimo de performance. O problema é que o mercado de internet é extremamente rápido, e existe uma pressão imensa para inovação. Neste cenário, gastar tempo em pontos pouco críticos pode ser desastroso, a medida que a busca por uma solução perfeita pode literalmente impedir que novas funcionalidades sejam implementadas.

Sempre fui adepto do “bom é inimigo do ótimo”, ou seja, a busca ininterrupta por uma solução ótima pode inclusive destruir uma solução suficientemente boa. Entretanto, quando falo “Keep it Simple”, quero dizer: uma vez diante de um problema, tente simplificá-lo ao máximo, crie atalhos nos processos e limite-se naquilo que atende suas necessidades. Não tente criar um canhão para matar uma formiga. Uma solução simples, no meu ponto de vista, é muito mais elegante e melhor que uma solução aparentemente genial. No caso específico de software, quanto mais simples for a solução, mais fácil é o handover para outros membros do time, perde-se menos tempo em desenvolvimento e em manutenção, mais fácil é o teste, existe uma menor quantidade de pontos de falha. Note que ao contrário do que parece, as soluções simples não abrem mão da qualidade em nenhum momento, pelo contrário, elas contribuem para o ganho de qualidade, principalmente à longo prazo. Implementar uma solução simples não significa desenvolver fora dos padrões ou não utilizar as best pratices conhecidas, tanto que, em alguns momentos, ela será mais trabalhosa.

A medida que os membros do time  compartilham esta idéia de simplicidade,  a velocidade do time aumenta, sem comprometimento da qualidade, e os débitos técnicos causados por problemas de implementação tendem a reduzir, uma vez que fica mais fácil integrar novas funcionalidades. No time em que faço parte (time voltado para o produto Globo Vídeos), acredito que todos já tem este mindset, de que entregar muitas coisas simples é melhor do que entregar poucas coisas muito complexas. Por isso, “keep it simple”,  e você vai ver o quanto as soluções simples podem ser extremamente eficientes.

5 comments so far

  1. Tiago Albineli Motta on

    É o famoso principio Kiss, Keep it simple stupid. Sem dúvida, as antigas idéias de querer fazer um framework para cada problema atrapalharam muito no passado.

  2. Guilherme Cirne on

    Muito bom. Concordo 100%.

    Sempre tento fazer isso. Mas às vezes é difícil, sempre rola aquela tentação de colocar “só mais uma coisinha aqui ou outra ali” e com isso perde-se o foco.

    Mas vale a pena o esforço de manter tudo o mais simples possível.

  3. Antonio Carlos Silveira on

    Adoro a frase “o bom é inimigo do ótimo”.

    Na maioria das vezes o bom é o que precisamos fazer.

  4. patricia on

    ola, gostaria de um exemplo de u projeto de engenharia com o princio kiss, grata
    patricia

  5. Rafael Pereira on

    Patricia,

    um exemplo clássico de kiss é o YouTube, ou o Orkut, ou até mesmo o Google. Em todos eles, o processo de engenharia de software foi baseado em um desenvolvimento incremental, como o proposto pelo Scrum. Em todos estes casos, podemos ver que inicialmente eles eram bastante limitados em suas funcionalidades “core”, ou seja, eram bastante simples e não apresentavam outras funcionalidades além daquelas essenciais para o funcionamento. Com o tempo, e com o feedback dos usuários, novas funcionalidades foram agregadas, como a tela cheia no YouTube, ou o Album de fotos / Vídeos no Orkut. Desta forma, o esforço é focado naquilo que o usuário julga importante, e a velocidade de entrega é maior. Imagine se o YouTube entrasse no ar apenas quando todas as funcionalidades estivessem prontas?!

    Este princípio pode ser aplicado em diversas situações, sendo que ele não está limitado ao desenvolvimento de software, apesar de ser mais comum neste mercado.


Leave a comment