Blog do Alone

Trabalho em uma empresa de tecnologia, especificamente desenvolvendo software, e também trabalho como freelancer nas horas vagas (que no momento são cada vez mais raras). Ganhei conhecimento e experiência participando como desenvolvolvedor,  a vezes como quadjunvante, nos projetos que apareciam, sendo que, a sua maioria eram de projetos WEB e alguns poucos eram de frameworks e desktops. Suas finalidades também eram variadas, desde serviços até websites para vender produtos, porém, uma coisa me deixava muito frustrado, a dificuldade de não saber elaborar uma interface intuitiva e ao mesmo tempo simples, resumindo, tinha inveja (e tenho até hoje) dos designs.

Dediquei meus estudos para conhecer linguagens de programação, frameworks, processos, padrões, boas práticas, ferramentas, etc, mas nunca me dediquei a aprender alguma coisa de design.  Digo que design não significa manipular imagens, HTML, CSS, Photoshop, etc. o termo significa muito mais que isso, significa ter em mente a melhor forma de apresentar um produto, impacto visual, chamar o cliente, ou melhor, possuir o “conhecimento artístico” de como tocar um cliente através da arte.

Vi que isso era de extrema importância depois tentar fazer uma interface, para uma necessidade específica, que iria utilizar em um projeto. Tinha a idéia mais não tinha capacidade para colocar em prática. Frustrado com minhas tentativas em vão, consultei alguns colegas que são web designs e solicitei uma ajuda no que eu estava fazendo. Depois de alguns minutos expondo minhas idéias ele me surpreendeu afirmando que eu não sabia o que eu estava fazendo, ou seja, tinha o problema, mas formulou sua resolução de forma errada.

Quanto mais ele falava mais ficava desapontado, pois realmente, o que eu tinha em mente não tinha bulufas com a solução do problema. Para tentar mostrar melhor, ele desenhou a interface toda na minha frente mostrando o porque de cada elemento contido na tela, achei isso fantástico, além do mais, ganhei a interface de graça e utilizo até hoje no projeto. Analisando isso, me questionei sobre a vantagem de ter designs em empresas que desenvolvem software, seja web ou não.

No ponto em que fui ajudado, todas as regras de negócio já estavam completamente desenvolvidas e testadas para solucionar o problema. Tratando a interface como um item sem importância, vi que estava completamente errado sobre quase tudo que tinha feito. Ou seja, o problema que aconteceu foi que não me preocupei com a apresentação para o cliente. É obvio que, tendo uma interface sem a regra de negócio o sistema não funciona, porém, se tendo a regra de negócio e não tendo uma interface funcional e também intuitiva o fator psicológico entra em cena. Isso é fácil de exemplificar; É só observar o comportamento de uma pessoa que utiliza uma família sistema operacional quase que

a vida toda e força-la  a utilizar um sistema sem sua interface que estava acostumada. Acreditem, já vi isso acontecer e quem se ferra é o setor de suporte.

Bom, voltando ao assunto, é óbvio que a necessidade de ser ter uma equipe de design é importantíssima. A Apple faz disso o seu principal elemento de desenvolvimento de produtos e venda, eles levam a sério o Design Funcional. A Microsoft incorpora o design no seus produtos voltados para usuários comuns e incorpora o design ao produto de forma intuitiva que ajuda o departamento de vendas a fazer o seu papel de forma agressiva.

Descrevi minha experiência frustrante de tentar fazer um trabalho de design sem o conhecimento adequado para isso. Respeito muito o trabalho desses caras porque, sem eles a web (WWW) não era um elemento tão atrativo como é hoje, e o marketing não seria são eficiente como é hoje.

[]s

Design, Off-Toppic Design

A maneira como desenvolvemos software tem influência direta no produto final, seja positiva ou negativa. Fases são importantes e principalmente a maneira com que passamos por elas no ciclo de vida do produto que está sendo desenvolvido. Para tal, aprendemos a utilizar os processos e boas práticas com o objetivo de agregar qualidade ao produto e conclui-lo no prazo especificado. Quem é, ou foi, aluno de faculdade deve ter vivenciado resenhas que ditam o mundo perfeito repleto de recursos separados por seus devidos papeis em um modelo cascata linear e com suas atividades e fases. Aprendem que um ambiente repleto de analogias e semelhanças e adaptações de paradigmas resolvem todos os problemas.

A preparação para tal inclui uma carga massiva de conceitos, boas práticas, UML e Java, bastante Java. Normalmente aprendemos que o Windows é uma porcaria e que o Linux é o melhor sistema operacional. Aprendemos utilizar meia dúzia de comandos e palavras reservadas de C e pensamos que somos programadores da linguagem. Ou melhor, recebemos uma carga de informações que, de certa forma, não são úteis para as tarefas profissionais.

Quando deixamos boa parte do jargão acadêmico para trás, ou melhor, quando iniciamos nossa vida profissional nos deparamos com situações completamente diferentes que requer sempre mais do que fazemos e uma carga de informação cada vez mais abrangente e atualizada.  Requer que você se adapte as regras de uma empresa e utilize as ferramentas que ela dispõe para você trabalhar.

A o iniciar um novo projeto de software, normalmente trabalhamos em etapas ou fases. Cada uma dessas fases tem suas particularidades onde a equipe, normalmente especialistas em suas funções, desenvolve seu trabalho para passar o resultado para a fase posterior. A particularidade é tanta que, em alguns casos, é necessário ferramentas específicas para a área. Porém, quando uma equipe consegue maturidade, principalmente trabalhando nas ferramentas que tem, sempre tem alguém afirmando que o desempenho deve ser melhorado e o que está impactado é a ferramenta que utilizamos.

Normalmente utiliza-se UML para desenhar diagramas em algum modelador para visualizar nossas idéias da forma mais genérica e abrangente possível. Normalmente, verifica-se que o modelo que desenhamos está enorme e nos convencem de que precisamos de uma ferramenta CASE para organizar melhor o nosso modelo, auto documentá-lo e ao mesmo tempo integrado ao sistema de controle de versão para disponibilizá-lo para outro participante. Posteriormente descobre-se que a ferramenta não foi projetada para integrar com o sistema de controle de versão utilizado pela empresa e nos convencem de que precisamos de um que se integre com a ferramenta para que possamos continuar nosso trabalho.

Utilizando nosso editor predileto iniciamos uma das fases mais importantes de um projeto de software; a codificação. Nosso editor nos permite trabalhar com diversas linguagens de programação, já que textos abrem em todo editor. Nosso compilador trabalha muito bem e faz tudo o que se propõe a fazer para que possamos trabalhar tranquilamente.

Criamos um buildscript que integra nosso ambiente (na verdade solto) e criamos algumas tasks para automatizar nossas atividades. Isso facilita muito a vida de quem lida com projetos com grande quantidade de fontes e que sempre tem que gerar builds em determinado dia da semana. Alguns, vendo que utilizamos ferramentas não semelhantes (normalmente em um terminal de comando) que eles sempre vão nos questionar se nossa produtividade está aquém do que foi combinado e outros vão indica-lo uma IDE para fazer o trabalho automatizado sem saber que o trabalho atual está automatizado.

Gosto muito de um artigo escrito pelo Akita onde ele fala da faca de dois gumes de utilizar IDEs para desenvolver softwares. Diga-se de passagem, gosto muito de IDEs, mas o problema é que geram um tipo de dependência que influencia em todas as suas atividades. Utilizo várias IDEs e sei do que estou falando. Desenvolvi muitos projetos com IDEs e alguns sem elas e vi que existem formas e maneiras, benefícios e malefícios, porém a dependência gerada é extrema.

Nelson.

Off-Toppic ide, uml

Não costumo adicionar conteúdo off-toppic nesse blog mas, pra quem gosta de boa música, essa versão de Stand By Me (John Lennon) com artistas de rua é brilhante. Parabéns ao pessoal da SXSW.

[]s

xLDen>pt GoogleC

Parabens

Off-Toppic musica

Olá pessoal..

Vi que muitas pessoas postaram em seus blogs resenhas e opiniões (muitas positivas) em seus blogs sobre o livro. Mas o que falarei aqui será sobre minha surpresa em observar a ligação entre conhecimento em outras áreas e a geração de idéias com bases em conceitos distintos obtidos em mundos recém conhecidos.

Uma vez passeando próximo a uma livraria, vi um livro que eu estava procurando a bastante tempo, na mesma hora entrei na livraria e comprei. Sempre tive simpatia pelos belos produtos desenvolvidos pela Apple, coisa que me levou a admirar e a respeitar as pessoas que estão por trás dessa grande empresa e principalmente o CEO. Steve Jobs.  Não é todo dia que um cara que foi praticamente chutado da empresa que fundou e volta das cinzas para com NEXiT, Pixar e por esculhambação entra pela porta da frente na Apple.

Esse fato realmente é uma tremenda vira-volta na vida de qualquer ser-humano e também aqueles que estão ao seu redor. Isso prova que o cara tem realmente uma estrela que só diminuiu a luz temporariamente. As dificuldades vieram a tona e através de um jeito inusitado e excêntrico, ou resumindo, criativo. O fato de ser multidisciplinar e flexível o levou a criar uma série de produtos premiados, com designs inovadores, simples e ao mesmo tempo funcional.

Bom, mas porque eu estou rasgando ceda pra uma pessoa que nem me conhece, por não trabalhar em sua empresa e por não gostar (apesar de funcionar) de suas técnicas motivacionais? O que me chamou atenção ao ler o livro de Leander Kahney foi simplesmente o fato de uma pessoa conhecer eletrônica, circuitos integrados, sistemas operacionais, caligrafia, arte, marketing, design e etc. Mas porque tantas coisas nada em comum? Isso é simples de responder.

Quando eu estava na graduação tive um professor de calculo que me falou o seguinte: “Se seu currículo está repleto de qualificações técnicas, então isso é excelente. Um mérito seu com certeza. Mas faça um curso de culinária, pintura, degustação de vinhos, dança de salão e coloque no seu currículo como atividades extras”. Logicamente quando escutamos isso achamos isso hilário. Mas ao ler esse livro vi que ao designar nosso tempo para atividades extra uma coisa boa pode acontecer. Pode despertar a criatividade com novas descobertas e ao mesmo tempo evitando ficar bitolado apenas com que você conhece, fazendo também aplicar o resultado dessas atividades no seu trabalho.

Isso aconteceu com muitos dos produtos da Apple. É possível encontrar traços das curvas dos BMW nos IPods, iMacs e MacBooks. Resultado das contínuas aulas de caligrafias e budismo onde surgiu a inspiração para Mac OS, Mac OS X e o Leopard. As inúmeras atividades alternativas que Steve Jobs o proporcionou (ou até ajudou muito) ser um cara extremamente criativo, com inúmeras idéias sobre produtos inovadores que vendem como água.

Quando temos o problema extremamente complicado e temos uma única ferramenta para solucioná-lo, pode até dar certo, mas com toda certeza será uma tarefa extremamente complicada. Ao ler o texto de Kahney percebi algo semelhante nesse sentido. Muitos de nós desenvolvedores de uma só linguagem vemos que todos os problemas do mundo, quando o assunto é software, podem ser resolvidos com aquela linguagem que você mais domina. Pode até ser que sim, mas se o problema for de complexidade extrema ou um problema com uma solução ótima abaixo do aceitável, com toda certeza a linguagem não será sua amiga. O que quero afirmar com isso é que problemas de prego não são solucionados apenas com martelos, sempre há uma solução mais apropriada fora do seu ângulo de visão. Então onde podemos encontrar a solução quando temos problemas dessa categoria? A resposta é simples: fora do seu ângulo de visão e alem do seu conhecimento. Tendo um amplo ângulo de visão é provável que elementos criativos venham a tona de forma natural, como um pensamento. Também problemas sejam resolvidos através de analogias.

A analogia, na minha opinião, é uma coisa banal quando adaptada a um segmento distindo. Na ciência da computação a analogia está entre os dois extremos. Um dos pontos positivos é adaptar conceitos se segmentos de um ambiente distinto, porém compatível, com em uma área paralela, porém distante.  Viajei um pouco nessa frase, mas se observar-mos essa idéia com carinho com certeza fará sentido. Vamos pegar um exemplo do nosso mundo: A engenharia é uma ciência que está presente na sociedade a séculos. A informática é uma ciência recente que alavancou nos anos 70, lógico que teve sempre em sua base a engenharia. Mas, o pior de tudo é emprestar o nome de “engenharia” para a disciplina de desenvolvimento de software. Isso tira toda a particularidade e dinamismo que está nos pilares da construção de software para uma analogia equivocada.

Tirando toda essa falta de criatividade que nos acompanha desde o início da nossa vida profissional, temos que ficar atentos para que o mundo dos paradigmas não nos perturbe, para que possamos expor nossas opiniões e principalmente fazer com que sejam aceitas sem a necessidade de quebrar a grande barreira que domina a mente humana dês do início dos tempos: a hipocrisia. É de se admirar que a maioria das produções inovadoras não venha de universidades e sim de empresas (texto de Vitor Pamplona). Isso pode ser explicado pele excesso de ego, burocracia e ao mesmo tempo a hipocrisia.

O tempo fez com que nossos pensamentos se concentrassem em uma determinada faixa de conhecimento. Abrir portas para outras áreas de conhecimento podem fazer de nós melhores pensadores e solucionadores de problemas utilizando ferramentas inovadoras e eficientes.

Off-Toppic apple, jobs, mac

Nunca pensei que uma vez na vida iria escutar Screeeeeeam for me Manaus. Sim, isso mesmo a donzela esteve aqui e fez muito barulho. Depois de um tempão sem adicional algum coisa aqui, não podia deixar de registrar uma coisa especial dessa, mesmo sendo um blog de tecnologia.

Abaixo vão algumas fotos do whow Maiden em Manaus, com direito a Ed Force One e tudo. Queria ter visto a cara dos controladores do SIPAM quando viram no radar o voo EDFI666…

[]s

Off-Toppic Iron Maiden, Manaus

Olá pessoal ..

Depois de umas férias merecidas, porque ninguém é de ferro, volto a tona para atualizar esse blog cheio de teias de aranhas.

Em primeiro lugar quero parabenizar o pessoal de Alagoas, especificamente de Maceió, por ter nos recebido de braços abertos e com sorriso estampado na face. Em segundo plano quero comentar a forma com que esse está caminhando.

Eita… que saudades …

Bom, vamos ao que interessa…. Li um post escrito por Vitor Pamplona na qual faz criticas acirrada sobre a forma de escrita de alguns blogs que se destinam a conteúdos da área de desenvolvimento de software (buzzwords, Liguagens, Plataformas, Comunidades, etc) não especificando a finalidade do blog em questão.  De certo modo, existe diversas questões a serem analisadas: Uma delas é o nível de conhecimento  e ao mesmo tempo a experiência do autor. Através desse ponto é possível ter, no mínimo, uma idéia do que sairá daí.

Concordo com o fato da experiência não ser um fator fundamental de aprendizado, mas é um ponto fundamental para um blog de tecnologia que necessita ter audiência. A experiência diz muito sobre o autor, em minha opinião, pesa mais do que uma certificação, títulos e premiações, mesmo sendo uma faca de dois gumes.

A escrita que utilizamos em blogs, na maioria das vezes, é totalmente livre de formalidades, pelo fato de tentar disponibilizar conteúdo para todo e qualquer tipo de pessoa. O fato de reclamar do estilo de escrita vai depender muito da finalidade na qual o blog foi criado. Um blog científico logicamente vai disponibilizar um conteúdo mais específico e com uma linguagem mais formal. Porém, um blog que se destina a fazer auto-propaganda vai disponibilizar um conteúdo mais despojado, voltado para um público mais variado. Não critico o fato de mudar a finalidade ou o estilo de escrita, mas sim a crítica feita de forma desnecessária para tal finalidade.

Tentar achar um meio termo para disponibilizar um conteúdo específico de forma didática, disponibilizando em uma linguagem compreensível para leigos e ocultando o mínimo de detalhes é o estado da arte. São poucos os que conseguem fazer isso, porém, a definição de níveis de escrita é relevante. Isso tudo dependerá do tema e da categoria do POST.

Os blogs deixaram de ser moda e viraram utilidade, tanto para diversão quanto para trabalho. Hoje é possível encontrar inúmeros blogs criados para diversas finalidades, porém, a sua utilização ainda é mal vista entre muitos da comunidade científica. A publicação de artigos através de blogs torna-se um conteúdo duvidoso para referencias de trabalhos científicos. Talvez isso aconteça pela falta de utilização da ferramenta ou até por barreiras de paradigmas, já que a comunidade científica é muito cuidadosa com os trabalhos publicados.

Uma solução para isso foi a criação desse “anel de blogs científicos“. Realmente foi uma idéia muito boa, mas sempre existirá aquele excelente trabalho autônomo publicado que não está no nesse anel de blogs, será que esse trabalho vai ter o devido valor. Categorizar é uma excelente alternativa, mas tentar restringir qualitativamente trabalhos conteúdos de outras pessoas é realmente uma decisão repleta de questionamentos e na minha opinião não é viável.

Existem inúmeros trabalhos científicos sendo publicados através de blogs, não apenas comentários, novidades, buzzwords, e outras coisas, mas sim trabalho científico mesmo. O blog virou uma alternativa, uma forma de dizer para todos a sua opinião, mostrar o que vocês estão fazendo.

No contexto atual, mm blog é uma ferramenta de extrema importância. Segundo Freedman, estamos vivendo um grande momento, a chamada era do Upload. É o momento de disponibilizar conteúdo, protestar, poder fazer com que os outros o leiam, ter a oportunidade de ser lido, ouvido ao assistido e ainda por cima ganhar dinheiro com isso tudo.  Porém, ser formadores de conhecimento através de blogs é uma alternativa um pouco arriscada, já que pode ser comparada como um trabalho científico com referências da WikiPedia, ou seja, referencia não confiável.

Off-Toppic Blog, Ciência, Conhecimento

Olá pessoal ..

Tendo em vista a competitividade que convivemos no cotidiano, é notável que no mercado de desenvolvimento de software, quem não se atualiza não tem muitas chances. Essa é uma pratica fundamental para quem deseja, ao menos, manter o seu emprego, além do inglês, certificações, bom comportamento, etc, etc, etc.

Bom, diante dessa realidade venho recomendar uma leitura fundamental para que deseja competir, tornar-se bom, produtivo e ágil iniciem a jornada lendo este livro:

Quem já leu sabe do que eu estou falando. Não é lendo um livro que você irá se tornar um excelente desenvolvedor, mas posso dizer que esse é o início. Li diversos trechos no ebook e gostei tanto que comprei uma cópia impressa, pra mim, ler ebooks é cansativo. O texto é bem claro e repleto de situações que convivemos em projetos de desenvolvimento de software. Os autores explicam como e qual a melhor forma de trata-las, mostra também uma série de boas práticas de desenvolvimento de software que devemos ter na manga para usá-las.

Com certeza, esse texto é material indispensável de qualquer desenvolvedor.  Taí a dica.

T+

Book, Off-Toppic Book, pragmatic

Mais um ano que passa e mais um ano que chega..

Bom pessoal, estou escrevendo o meu ultimo post de 2008 agradecendo a todos que visitam este blog. São lembranças boas, principalmente o fato de compartilhar conhecimento com vocês através desse blog, por ser também um principiante no mundo dos blogs, e de levar conteúdo de relevância para vocês leitores.

Agradeço a todos os leitores, a quem comenta e que apenas da uma olhada.. A todos um excelente ano de 2009.

[]s

Off-Toppic

O Mantis é um Bug Track System muito eficiente e simples de utilizar e instalar. Muitos utilizam essa ferramenta para registros de bugs, acompanhamento de projetos, suporte de software e etc. Mas poucos sabem que a ferramenta possui recursos interessantes de integração.  Entre esses recursos está o suporte a Web Services através do WSDL disponibilizado pela ferramenta.

Confesso que foi um pouco ruim de encontrar esse recurso, mas, devido a necessidade de integração com a ferramenta BugHunter que estava-mos desenvolvendo, tivemos que vasculhar um pouco a estrutura do Mantis para compreende-la para ter um feedback suficiente para integrar a ferramenta com a aplicação. Bom, pra quem não conhece, segue a dica:

• No caminho MantisDir\root\mantis\api\soap temos o arquivo mantisconnect.php. Nesse arquivo encontra-se o WSDL e as interfaces publicadas que disponibilizarão os serviços para os clientes.
• Portanto, em qualquer mantis de 1.1 para cima (testei apenas nessa versão), basta acessar a URL que leva até esse arquivo para ver seu WSDL e a descrição das interfaces publicas.
• Após isso, obtenha o endereço do WSDL e gere os stubs com seu framework predileto e integre-a a sua aplicação.

A principal dificuldade que encontrei foi na adaptação de alguns tipos complexos gerados pelo Apache AXIS II, mesmo tendo projetado a aplicação para que o processo de integração fosse com o mínimo de traumas possível. Mas no fim saiu tudo bem.

É verdade, sei que não coloquei nenhum material ou passo-a-passo ilustrado mostrando essa façanha, mas por falta de tempo isso ficou impossível. Estarei fazendo, em breve, um tutorial mostrando os passos para a integração.

Até breve…

Off-Toppic

O Termo nos diz tudo: Fábrica, material, estoque, linha de produção, pessoas executando a mesma tarefa, término, executa novamente, exaustão, problemas de saúde, etc. Se levarmos essa analogia para a área de desenvolvimento de software seria mais um grande equivoco que estaríamos cometendo. Coisa que ocorre com muitos CIOs e gerentes.

Quando disse que isso seria uma analogia equivocada, vamos primeiro definir o termo analogia. Segundo a Wikipedia, a analogia é uma relação de equivalência entre duas relações. Segundo o Wiktionary, analogia é a explanação de uma relação entre dois elementos, comparando o mesmo com outros relacionamentos.

Segundo o termo descrito, quando tentamos fazer uma comparação de um processo completamente dinâmico e complexo com uma definição, que não se sabe ao certo quem definiu, sendo Taylorista partindo do início do século, estamos cometendo um erro. Pois, quando pensamos em uma Fábrica, especificamente de sapatos, dá para compreender no mínimo que lá se produz sapatos, a mesma coisa para software, porém, com uma diferença enorme.

Ao iniciar a produção de um software, estamos entrando em um dos ciclos mais dinâmicos e complexos que existe. Produzir software não significa executar, como a analogia define, e sim projetar. O software é o resultado de um conjunto de tarefas completamente intelectual onde não há repetição. Ao falar em software devemos ter em mente a existência de pessoas extremamente gabaritadas com conhecimento em hardware, linguagens de programação, frameworks, bancos de dados e no problema na qual o software destina a resolver. Quando produzimos um software, não estamos produzindo uma cópia, e sim um produto específico, original e suscetível a mudança.

Portanto, fazer analogias de atividades que pertencem a segmentos distintos, coisa que é normal na ciência da computação, torna-se um processo equivocado. Cada área segue um princípio que é apoiado por uma base de conhecimento que é adequado ao seu segmento de atuação. Atribuir analogias de uma atividade para uma área distinta pode ocultar muitos detalhes específicos de uma atividade, fazendo com que a identidade de seu segmento seja mal compreendida por pessoas que seguem um paradigma.

A utilização de paradigmas em acesso é extremamente prejudicial para a disciplina de desenvolvimento de software. Isso porque são conhecidos, erroneamente, como boas práticas de desenvolvimento. Na verdade, muitos são dignos de levar o nome de “boas práticas”, já outros, são casos de sucesso que deram certo apenas para um determinado segmento ou situação.

Utilizar paradigmas sem questionamentos sobre seu benefício na solução do problema significa que estamos bitolados. Não critico a utilização de paradigmas, critico a utilização de paradigmas sem o questionamento de sua real utilidade. Isso se aplica de forma extravagante na engenharia de software, pois demonstra total dependência de técnicas e procedimentos que é resultado da evolução da ciência.

paradigma

O fato de utilizar uma abordagem, sem questiona-la, sobre sua real utilidade estará nos encorajando a sempre seguir as mesmas regras, até mesmo para segmentos distintos. Um dos principais remédios para isso são as mudanças.

A mudança é o elemento crucial para o sucesso no desenvolvimento de software. O dinamismo e a colaboração andam lado a lado com esse princípio. Ser dinâmico é ser funcional. Não é atoa que existe uma área específica na engenharia de software para gerenciar mudanças. Então, porque não torna-la mais dinâmica do que já são.

Além das mudanças, outro quesito que as complementam são as interações e colaborações. Característica encontrada em abundancia no mundo de open source. Nos primeiros contatos com essa idéias normalmente ficamos encantados e surpresos ao vasculhar os fontes do kernel (ou apenas Linux, já que é o nome do núcleo). Já outros questionam sobre o processo utilizado pela Apache para dar conta de tantos projetos. A resposta para tudo isso está na colaboração, interação e contantes modificações. Não existe um processo burocrático que limite o pensamento e a criatividade dos desenvolvedores. Todos são livres para pensar e expor idéias. Esse é o segredo.

kernel

No mundo open source não existe processos que regem as regras e normas para desenvolver um software. Existe sim muita colaboração entre os envolvidos no projeto. Colaborar é o segredo. Isso mantém as pessoas motivadas e livres para pensar. O que eu quero dizer com isso é que: quanto menos nos preocuparmos com documentações excessivas, modelagens, processos, entre outras coisas burocráticas, sempre teremos problemas com prazos e qualidade. Isso inibe a criatividade de quem participa está participando da atividade pois, sempre haverá uma atividade planejada posterior a que você esta exercendo. Coisa comum em uma fábrica de software.

Defendo que o desenvolvimento de software é 80% arte, resultado de uma inspiração motivada por um despertar criativo, e o resto é o resto. Defendo também as palavras de Domenico de Masi quando diz que o “ócio também pode ser criativo”. Também guardo a célebre frase: “A Imaginação é mais importante que o conhecimento”, proclamada por ninguém menos que Albert Einstei.

O resultado de todo esse alvoroço é que algumas empresas de tecnologia mudaram a sua visão e muitas já nasceram com isso. Uma delas é a Google. Fundada por dois jovens geeks, decidiram incluir o conceito de liberdade e colaboração em sua empresa, ou seja, resolveram fazer da empresa algo semelhante a um compus universitário. O resto você sabe o resultado.

As metodologias ágeis seguem o mesmo conceito. Além do mais, incluem o conceito de colaboração em suas atividades principais, como codificação, reuniões, interações e até mesmo nas comemorações de entrega de release. Já participei de coisas como essas e garanto que é bem divertido.

Fazer analogias entre elementos distintos quando não há compreensão de suas raízes é uma atividade normal, porém, fazer analogias de forma copiosa, isso se torna um problema. A área da informática faz isso frequentemente e muitas das vezes não apresenta um resultado óbvio. Tentamos ser como a industria automobilística, construção civil ou até mesmo com acadêmicos de filosofia porém, nos esquecemos de quem somos, de nossas particularidades e raízes.

Fabricas não são lugares para interações e muito menos para a criatividade. São lugares que exigem que faça o mesmo serviço para montar um mais produtos, apenas isso. Portanto, afirmar que uma empresa de desenvolvimento de software se assemelha a uma mera fábrica é resultado de uma errónea analogia, que tem como base uma área pouco compreendida em comparação com a áreas de segmentos distintos.

Bom, acho que falei demais. Tomei cuidado para que esse texto não soasse com um tom de desabafo e ao mesmo tempo pejorativo e sim esclarecedor, pelo menos tentei.

Off-Toppic analogia, fabrica de software, Metodologias Ágeis