Desenvolver software é como dirigir

24jul07

Analogias são uma maneira poderosa de explicar algum conceito: parte-se de um principio já conhecido e estabelecido para tentar explicar ou mesmo formar um outro. Tome como exemplo explicar uma escala baseada em outra (“se X é um fusca, então Y é uma ferrari”): o conhecimento prévio sobre um fusca e uma ferrari é transportado para X e Y, seja lá o que forem. Mas, apesar de analogias serem usadas como uma ferramenta poderosa para dar explicações, algumas podem apenas direcionar para concepções erradas e por vezes desastrosas. Em desenvolvimento de software não faltam analogias. Desenvolver software é como construir prédios; é como criar uma linha de produção; é como fazer um filme e tantas outras que não chegaram a ganhar algum destaque.

Traffic due to filmingEmbora algumas analogias pareçam completamente razoáveis, sequer chegam perto do que é realmente desenvolver software. Não é como construir casas. Derrubar e repintar paredes é, por vezes, trivial em software, mas não é quando se trata de cimento e tijolos de verdade. Começar de cima para baixo não é razoável quando se constrói casas, mas pode ser quando se desenvolve software. Não é como uma linha de produção porque não existem, nos bons projetos de software, divisões tão fortes e distintas separando cada uma das fases. Por fim, não deveria ser como fazer filmes já que estouros de tempo e orçamento não são bem vistos e eu nem preciso de uma analogia para explicar isso. Mas existe uma analogia que eu considero certeira: Desenvolver Software é Como Dirigir. Ela foi feita por Kent Beck no eXtreme Programming Explained: “Driving is not about getting the car going in the right direction. Driving is about constantly paying attetion, make a little correction this way, a little correction that way”. No livro esse trecho é usado para dar uma idéia a respeito XP, algo sobre não criar planos impossíveis de serem seguidos por resistirem às mudanças. É sobre como é mais sensato pensar onde se quer chegar e reagir de acordo durante o caminho, da mesma maneira como é dirigir: você pensa onde quer chegar, pensa nos caminhos e reage a engarrafamentos, acidentes, semáforos, buracos e pedestres.

Só que nós podemos levar essa analogia um pouco além.

Uma porção de motoristas, a maior parte que eu conheço, para falar a verdade, tem algum seguro contra acidentes ou roubo. Seguro é uma maneira que os motoristas encontraram para se proteger quando algo extremo acontece – caso de um acidente ou roubo. Mas não são os únicos mecanismos já que temos air bags, cintos de segurança, freios de ultima geração, e mais uma porção de acessórios prontos para nos ajudar nesses casos extremos. Entretanto, bons motoristas sabem que nem seguro e nem acessórios são itens melhores do que direção defensiva. Você não acelera mais do que o necessário porque existem limites de velocidade, não ignora sinais vermelhos, se mantém atento quanto aos outros carros para ficar a uma distância considerada segura. E isso o tempo todo, afinal é melhor ser cuidadoso do que experimentar os air bags. Acidentes causam muitos danos: lesões físicas, traumas, falta de confiança – para esta última, basta perceber como a maior parte dos clientes encara com desconfiança os projetos de software.

Com software não é diferente. Você pode até ter seguros, geralmente em forma de contratos estipulando perdas e ganhos quando casos extremos acontecem, mas se manter atento para evitar acidentes é mais razoável, principalmente quando é o passageiro – no caso o cliente – quem sofre mais com as conseqüências. Boas práticas, testes automatizados e integração contínua são algumas maneiras que os bons desenvolvedores encontraram para dirigir defensivamente, elas dão suporte para reagir quando o trânsito muda e ajustes precisam ser feitos. Não pára por aí, assim como bons motoristas se preocupam em oferecer feedback aos outros (vide as sinalizações feitas, ou mesmo alguém alertando sobre uma porta aberta), bons desenvolvedores se comunicam bastante para prover as setas e alertas necessários.

Já passamos por muitos acidentes, tanto em desenvolvimento de software quando na direção de carros. Outros acidentes virão, seja por nossa culpa ou por causa de desenvolvedores desavisados, mas é preciso aprender com cada um deles para criarmos softwares melhores.

Anúncios


18 Responses to “Desenvolver software é como dirigir”

  1. Vale lembrar que as analogias são consistentes até certo ponto. Uma analogia nunca representa fielmente um conceito, uma idéia ou a sua implementação.

    Na analogia dos motoristas, por exemplo, perde-se o sentido quando se pensa no choque entre dois motoristas ou desenvolvedores. Da mesma forma, se o desenvolvimento de software é como dirigir, uma equipe de desenvolvimento é vista de que forma? Como um grupo de motoristas indo para o mesmo local? Se for assim, todos eles farão todas as tarefas ou trajetos, o que não ocorre numa equipe. Talvez seja visto como caroneiros, porém o revezamento na hora de dirigir, assim como a limitação das vagas em um carro, não existe num time de desenvolvimento.

    No entanto, concordo com o Marcos, essa analogia para desenvolvimento de software é a melhor que já vi. Gosto dela principalmente por me deixar pensar que com ruas bem sinalizadas (um código bem escrito), ninguém precisa de mapas (documentação), embora que, quando se entra em uma cidade desconhecida, um mapa sempre ajuda.

    []s Marcos e parabéns pelo post!

  2. Vitor, a idéia era mais comparar desenvolvedores de maneira individual, já que dirigir é uma tarefa relativamente individual. Talvez eu até pudesse deixar a analogia mais larga para pensar em mecânicos, guardas de trânsito, etc. Mas prefiro que as pessoas critiquem a analogia – como vc fez – e entendam que ela não explica desenvolvimento de software como um todo porque, no final das contas, ainda são assuntos diferentes.

    No mais, quando é que tu volta a escrever?

  3. > No mais, quando é que tu volta a escrever?

    Assim que eu fizer o priki ter RSS e uma página diferente para os últimos posts 🙂

    []s

  4. 4 Wendell Raphael

    Não sei dirigir.
    Agora entendo o porquê do C++ nunca ter entrado em minha cabeça…

  5. 5 Leandro de Souza(Leandroso)

    É realmente boas analogias facilitam bastante o aprendizado e a compreensão, principalmente para aqueles que são leigos como eu. Gostei muito do que tu dissesse que elas podem tanto ajudar como, complicar bastante quando mal construidas.

    E digo mais essa analogia da “direção” pode e deve ser aplicada a qualquer tipo de desenvolvimento a longo(ou curto)prazo, passível de modificações e acidentes não previstos.É como diz o popular “É melhor previnir do que remediar.

    Sei que meu comentário não está muito dentro do contexto “Software Developer”, mas como um “Life Plans Implementer” posso afirmar tranquilamente que essa analogia é consistente e viável.

    Saudades parea,

    Abração Leandro.

  6. Comentando o comentário de Leando (logo acima). Concordo com o ele. Só queria comentar que o “prevenir é melhor que remediar” aplicado a desenvolvimento de software me lembrou o “Responder a mudança é mais importante que seguir um plano”. O prevenir pode dar a idéia de que é melhor planejar toda a viagem, antes de partir, e tentar seguir este plano. Isto é ruim, pois não há como saber com segurança em que locais e quantos pedestres, outros carros, buracos, desvios, etc… serão encontrados no caminho. Seguir um planejamento detalhado engessa e inibe adaptações durante o percurso. O remediar é interessante quando aplicado em pequenas e repetitivas doses, soa como adaptar, ou seja, o percurso vai sendo percorrido e os pequenos imprevistos vão sendo remediados com base no feedback da própria viagem. 🙂
    Abraços!

  7. Vinicius, mesmo pensamento. Para mim, o prevenir é se preparar para mudar, como é o caso de TDD, por exemplo. Criar um ambiente resiliente, onde a mudança seja acomodada mais facilmente, é bem mais interessante do que se prender a um plano feito quando a verdade era outra, e como bem sabemos, verdade é o que conhecemos em determinado momento.

    ps.: Legal o teu blog, coloquei na blogroll daqui.

  8. Marcos, parabéns pelo novo blog. Pelo que vi, a idéia é ter controle do dinamismo sem perder a dinamicidade.

    O interessante é como manter uma certa disciplina sendo dinâmico. O trânsito tem regras: cabe a nós obedecê-la para os softwares, que não são regras fixas e não tão constantes assim, mas sabemos que entre todas elas temos algo em comum.

    Favorecer uma linguagem comum, disciplinar, controlada e flexível é o caminho para colocar ordem no caos.

    Não enrijecer o caos, vamos caminhar com ele!

    T+

    Glaucio.

    P.S.: Seria legal perguntar a alguém que manja de sistemas dinâmicos (é aquelas da física mesmo) se nós temos chance de aprender algo com eles dentro do nosso próprio universo.

    ae

  9. 9 Thiago Leite.

    Se fôssemos colocar nessa história os seguintes atores:

    – Carro;
    – Caminho;
    – Ponto de chegada.

    Quem seriam os personagens?

    Pra mim o carro seria a equipe de desenvolvimento, o caminho toda a fase de construção do software e o ponto de chegada o perfeito funcionamento do software no cliente.

    Abraço,

    Thiago

    Obs: BOm artigo Marcos.

  10. Adorei a analogia de dirigir carro. Imagina um cara que treinado, ou “lobotimizado” em CMMI tentando dirigar no estilo “waterfall”. Ele traça um plano no mapa, estebelece os riscos, pega a assinatura do cliente e parte para a rua. Cruzando o primeiro moto-boy ele vai ter que congelar o projeto, escrever um change request e revisar o project, pois isto não estava previsto. Eu que não queria cruzar no caminho dele…

    Brincadeiras à parte, o texto ficou muito legal, parabéns.

  11. Esqueci de comentar mais uma coisa: É impressionante como alguns clientes agem de forma irracional em relação ao seu “seguro” quando lidam com fornecedores de software.

    Eles realmente acreditam, ou fingem acreditar, que como está escrito no contrato, o fornecedor irá cumprir, não interessa o que acontecer no meio do caminho. Isto é como dirigir de olhos vendados, só porque você um seguro de carro.

  12. Olá, Marcos.
    Essa msg era pra ir por email, mas não encontrei, então vai por aqui. Pode apagar após ler, se quiser.
    Obrigado por adicionar um link para meu blog. Fico feliz com a divulgação.
    Vou adicionar o seu também. Começou com um ótimo post. Parabéns!
    Aguardo o segundo. 🙂

  13. 13 Fabio Jose

    Pensar. Repensar.

    Seriam os motoristas da Viação Cometa os verdadeiros criadores do windows ?
    Com uma bagagem de 200 viagens na Dutra, poderia pleitear o cargo de IBM-CEO ?
    Ultrapassar pela direita significa que recorro muito nos codigos alheios ?
    Atropelar um cachorro no acostamento significa deixar um bug no .hlp ?
    Ouvir CD no carro = baixar MP3 na net ?
    Esta história vai longe…

    Por isso me sinto conservador em ver a Internet como um marzão em vez de uma autopista, onde cada portal é um porto(e não um estacionamento), cada blog uma caravela(não um carro), cada function uma leve brisa(nem pensar no pedal do acelerador).

    Se a qualidade da banda do speedy tem alguma relação com as cheias das marginais, eu até acredito. Mas “dirigir é preciso, navegar não é preciso (…)”

    Marcos, sua analogia está expondo seus maiores problemas no momento:
    O trânsito de SP, intoxicação por obj.class, e muitas idas ao self do MASP. Viaja um pouco cara. Mas viaja de navio, que tu vais ver a criatividade se “esbaldando”
    🙂


  1. 1 Fábricas de software - Uma analogia levada longe demais « Mergulhando no Caos
  2. 2 Passeio pela blogosfera - vida inteligente encontrada « Salada Digital
  3. 3 ExpressoJava» Blog Archive » Desenvolver software é como dirigir
  4. 4 Fábricas de software - Uma analogia levada longe demais at Mergulhando no Caos
  5. 5 rachat Permis

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s


%d blogueiros gostam disto: