Pense. Porque nós fazemos software?

Você faz software por que outras pessoas precisam dele. Muitos desenvolvedores, mesmo os mais experientes esquecem algumas vezes que o motivo da construção do lindo software que eles estão fazendo é que alguém precisa do sistema para realizar alguma tarefa e eles só vão usar o sistema se ele atender as suas necessidades.

Não importa o quão lindo seja o software tecnicamente, ou quais técnicas e padrões de projeto foram usados na construção do sistema, no final das contas, alguém precisa usar e esse é o motivo de tudo. Essas afirmações tem vindo a minha cabeça ultimamente porque tenho “esbarrado” com muitos artigos e decisões sobre “qualidade” VS “entrega”, diversas são os artigos dizendo a você, quase que como um hino: “Não negocie qualidade.” Eu particularmente discordo, construir algo do zero não é fácil e como tudo na vida, decisões aplicadas ao contexto devem ser tomadas e muitas vezes, o problema é que a falta da qualidade no prazo solicitado não é deixada clara para quem solicitou, ou mesmo que o plano de negócio da empresa não está alinhado com o direcionamento da TI, ou mesmo que não existe plano de negócio.

O fato é que no fim das contas alguém tem de decidir entre entregar valor ao cliente e produzir o melhor software em aspecto técnico, com a melhor estrutura, performance e etc.

Eu particularmente acho que o problema não está no débito-técnico produzido momentaneamente, eu vejo um problema muito maior na falta de alinhamento entre o que é produzido e a estratégia da empresa.

E o que foi produzido para uma demanda pontual, pode ser refeito logo em seguida, desde que os custos adicionais fiquem claros para quem solicitou.

Casos como esse provavelmente aparecem todos os dias, custos adicionais com testes, falta de arquitetura bem definida, problemas com reuso de componentes mal projetados, esses fatores são provavelmente resultado de desconhecimento de engenharia de software ou de decisões de negócio mal planejadas.

Certa vez, tive de lidar com uma demanda relativamente fácil de implementar, porém, o componente que deveríamos alterar era utilizado em uma das áreas de mais demanda do sistema e que operava 24h na empresa, tínhamos 2 dias de prazo para realizar a alteração ou informar a diretoria que não atenderíamos a demanda.

O problema maior não era a dificuldade técnica, mas, a extensão dos testes que teriam de ser feitos e já estávamos no final do sprint, sem falar que os fornecedores de outro estado e outra operadora dependiam da alteração, ou seja, em termos de negócio, o prejuízo seria enorme.

Eu sugeri uma abordagem diferente e “errada”: Minimize o risco, copie o componente atual, modifique e aplique na área que precisa dele.

Uma revolução foi disparada entre os desenvolvedores, eu que sempre defendi fazer o certo, estava sugerindo uma gambiarra, logo obtive a resposta padrão: “faça certo da primeira vez”. Tentei expor os motivos para realizar a gambi, final de sprint, testar o sistema todo sem scripts automáticos, testar as outras alterações realizadas no sprint, horas adicionais de desenvolvimento e alto risco de para o setor por causa de problemas nessa área, novamente, a resposta padrão: “faça certo da primeira vez”.

Pois bem, no final das contas, aconteceu o pior, introduzimos um problema no componente que fez com que tivéssemos de retirar do ar a nova versão do sistema, isso por causa de brilhantismo técnico, depois do transtorno, fica a pergunta, pensamos sempre em entregar mais valor de negócio para o cliente, equilibrando o desafio técnico com a necessidade?

Bom, vou tentar deixar aqui um conjunto de conselhos para que vocês meditem comigo:

1. Lembre sempre, o motivo da construção do software é uma necessidade do cliente. A engenharia de software ajuda você a fazer o um software melhor, mais fácil de manter, com mais qualidade, mas, lembre sempre que sem usuário não existe sistema e que as oportunidades para o sistema podem não esperar você. Veja o exemplo do “Segundo sistema” no livro: o mito do homem-mês.
2. Avalie o impacto. Algumas alterações não são estratégicas e as pressões associadas são somente fogo de palha da diretoria, na verdade, as vezes nem existe um plano para utilização do recurso em questão. Mas, em certas horas, o seu brilhantismo pode aumentar drasticamente os custos do projeto, ou mesmo impossibilitar a utilização do sistema simplesmente porque você foi tão lento que deixou o momento certo passar. Mas, não se engane, não se venda, deixar a qualidade de lado sempre é uma decisão difícil e não existe uma fórmula mágica para decidir o que fazer, dependendo do que for solicitado, eu posso estar errado e o melhor seja dizer não.
3. Deixe as coisas claras. Se você decidir fazer do jeito aparentemente mais fácil, lembre de deixar isso claro para quem pediu e para não levar a culpa depois. Se puder registre formalmente e questione porque as atividades técnicas não estão alinhadas com o planejamento estratégico.
4. Se precisar, refaça. Depois de entregar a funcionalidade, verifique se o que foi entregue realmente tinha tanta importância e se realmente tiver, comece a refazer ou agende tempo para isso, para que sua equipe não acumule débito-técnico desnecessariamente em uma parte importante do sistema e, caso não seja usado, não gaste tempo e dinheiro refazendo algo que não tem valor para o cliente, pegue o caso discuta com os gestores para tentar alinhar o planejamento com o operacional.
5. Refaça seu planejamento. Uma mudança de rumo não é motivo para você deixar a organização de lado. Destrua o sprint, direcione as atividades para o maior valor de negócio, crie um branch, mas, faça tudo isso sabendo quando e o que você tem de entregar e principalmente, informe a todos o que você vai deixar de entregar. Opa, esqueci de mencionar que usamos scrum, adeque se julgar necessário, ao seu processo.
   

Um pouco de sistemas operacionais

Senhores,

Mais um artigo publicado recentemente, sobre a montagem de um ambiente de testes para desenvolvedores de Sistemas operacionais, durante um fim de semana em que eu tinha menos coisa pra fazer, montei um ambiente, desenterrei meu livro sobre SO que estava na estante e foi brincar :D

Na hora de testar os códigos acabei produzindo um "concatenardor-de-arquivos-para-uma-imagem", para poder criar uma imagem de disquete fake e usar em uma VM.

Fiz um artigo que resume a histórinha e enviei para um site sobre o assunto, eles gostaram e publicaram ... segue o link:

http://www.numaboa.com/informatica/oficina/215-so/1166-virtual-pc

tecnologias usadas: Visual Studio como IDE, .net framework, Virtual PC, seja feliz com o artigo ou não :-)

Melhorias de Performance em aplicações Web - part I

Uma área bastante abrangente na atualidade e que tem despertado o meu interesse é área de redes, particularmente a camada de aplicação, mas, quem sabe eu possa passear por outras camadas mais tarde.

Um exemplo é um protocolo de aplicação que é relativamente simples e que faz um enorme sucesso, bem como, tem uma importância realmente fora do comum, o protocolo http.

Muitos "desenvolvedores" desenvolvem aplicações para Web, como aplicações com ASP.NET, sem nem ao menos saber como funciona a arquitetura da rede e isso tem impactos claros na forma como suas soluções são implementadas, implicando muitas vezes em problemas de performance.

Recentemente comecei a fazer uma pesquisa sobre performance para aplicações Web, já que trabalho em um projeto onde estamos utilizando muito Ajax e muito JQuery com o objetivo de tornar nossas páginas mais rápidas. A questão que começou a me intrigar é justamente, como definir performance para aplicações Web? Quais os problemas que enfrentamos e onde gastamos nosso tempo?

Comecei analizando o back-end das aplicações e vi que a mais lenta de nossas procedures levava 3 segundos para retornar os resultados e a maioria das outras excuções de banco durava menos de 1 segundo. Então, logicamente, nosso problema de performance não estava no banco de dados, resolvi "subir" uma camada e passe para o tempo de execução dos códigos no nosso servidor de aplicações, foi ai que tive de procurar um meio de avaliar o tempo entre a solicitação de uma página e a sua montagem no browser.

Ou seja, o problema era no modo como o código estava escrito ou precisavamos diminuir o peso de algumas páginas. Fui pesquisar sobre perfomance de front-end. Ai as pessoas começam a dizer: "javascript! Ajax! javascript!!" e eu digo calma, vamos entender melhor o que acontece.

Outra coisa interessante, eu pensei comigo mesmo, alguém já deve ter pesquisado isso na vida, tenho que encontrar algum artigo ou material sobre o assunto. Foi ai que encontrei o site do Steve Souders (http://stevesouders.com/) e o seu livro. Bom, foi ótimo porque assim que comecei a leitura do livro ficou claro a importância de conhecer como a coisa funciona por baixo. Percebi que mesmo as nossas páginas que já eram rápidas, poderiam melhorar significativamente, simplesmente seguindo algumas das recomendações do livro e tendo cuidado com onde "colocamos as coisas".

Vamos entender melhor, primeiro vejamos como funciona o protocolo HTTP. Esse protocolo que é de uma simplicidade empolgante para os engenheiros curiosos como eu, funciona fazendo requisições de objetos a um servidor que fornece os objetos a medida que eles são encontrados.

Sabendo disso, já fica claro onde você pode ter alguns problemas, por exemplo, é provável (mas, não é certo) que você tenha uma página mais lenta se fizer muitas requisições sem motivo aparente, só por preguiça de arrumar o projeto.

Cada requisição passa por um monte de etapas que vão somar tempo a carga da página que você está pedindo. Por exemplo, a cada pedido, é feita uma resolução de nomes (DNS), o servidor procura o cara e envia para o seu computador, mas, nesse meio tempo, a rede pode estar congestionada, o TCP pode enviar millhares de pacotes de confirmação, e todo esse tempo é somado a sua página.

Imagine o caso em que você tem um conjunto de ícones de um menu, pelo menos uns 12 icones, cada um será uma imagem que precisará ser solicitada ao servidor. No lugar de fazer sua página sofrer com 12 requisições, porque não mapear as imagens em um único arquivo? :-)

São coisas como essas que estou lendo, a medida que for descobrindo coisas legais a eu vou colocando aqui.

Abraço para vocês.

Zune e XNA e jogos.

Bom, como todos já sabem, eu geralmente gosto de falar um "pouco" sobre XNA, então la vai mais um post sobre o assunto :-)

Muitos, mesmo os que não são desenvolvedores, devem conhecer o Zune (http://www.zune.net) que é um player da Microsoft e concorrente do Ipod. Porém, o que "poucos" sabem é que, além de poder desenvolver jogos para o PC e para o XBOX, também é possível desenvolver jogos com o XNA para esse pequeno dispositivo portátil.

Esse recurso foi incorporado a plataforma na versão 3.0 do XNA.

Se você é curioso como eu, além de pesquisar nos sites técnicos sobre xna, pode ver um pouquinho de um game rodando no Zune nesse endereço:

http://www.youtube.com/watch?v=GiXfPfx94lM

abraço.

Resumão :-)

Ao final de mais um ano eu sempre procuro realizar uma reflexão sobre as minhas conquistas e sobre as coisas que deixei de realizar. Felizmente, dentre as coisas que eu planejei realizar, poucas não foram atingidas, tanto profissionalmente como pessoalmente.

Profissionalmente as minhas maiores mudanças foram a troca de emprego e a minha nomeação como MSP, aproveitando, vamos fazer um pequeno resumo do meu passeio nas faculdades divulgando a tecnologia Microsoft, só me desculpem a qualidade das imagens, algumas são do meu celular que não é lá uma “brastemp” ;-)

Faculdade Guararapes – O Mercado de Jogos e desenvolvimento de jogos com XNA

Estavam presentes nesse evento, pessoas como Caio Ferraz e Marden Menezes.

CEFET-PE – O Mercado de Jogos e desenvolvimento de jogos com XNA

No CEFET-PE, Daniel Ferreira pensativo, aguardando para falar sobre ASP.NET e tecnologias Web. Abaixo vocês podem ver como Edgar e Daniel são fotogênicos, principalmente Edgar. ;-D

FIR – O Mercado de Jogos e desenvolvimento de jogos com XNA
Como vocês podem ver eu realmente gosto de falar sobre XNA ;-) esse foi legal porque tinha muita gente e muita gente interessada no assunto.

Abaixo o pessoal se preparando para o evento, Daniel, Lucas e Agenor ;-)

Uma coisa muito legal nesse evento foi a presença de um “tradutor” para pessoas com necessidades especiais, enquanto íamos falando um professor ia traduzindo para linguagem de surdo-mudo, vide imagem abaixo.

UNICAP – O Mercado de Jogos e desenvolvimento de jogos com XNA

Esse evento foi um pouco mais leve em relação ao da FIR, pela quantidade de pessoas, mas, foi legal interagir com o pessoal da Católica, estive por lá a convite de Felipe Pimentel que trabalha no mesmo projeto que eu na Inove.

Desculpe a qualidade da foto, mas, como já disse antes, meu celular é uma porcaria para fotos L segue abaixo uma foto do anfitrião, concentrado na atividade de passador de slides ;-) (logo em seguida eu assumi o posto)

AESO – Windows Presentation Foundation
Bom, ninguém pode dizer que eu falo somente sobre XNA, mas, bem que eu gostaria.Esse evento foi legal porque, além de palestrar sobre algo diferente, eu tive como companheiros de palestra Luciano José que falou sobre XNA (administrador do Sharpgames) e Rebeca (nossa anfitriã que falou um pouco sobre programas acadêmicos).

Rebeca e eu falando sobre programas acadêmicos e Imagine Cup.

Eu começando a apresentação sobre WPF, vê a pose de “super herói”.

ECAPE (AESO) – O Mercado de Jogos e desenvolvimento de jogos com XNA

Bom, esse foi mais complicado por que além de palestrar eu também ajudei na organização do evento, e putz, dá trabalho. O legal foi que esse evento tinha um foco diferente, os outros eventos eram direcionados a pessoas que não tinham um conhecimento prévio das tecnologias Microsoft, esse já era direcionado ao pessoal das células acadêmicas. O mais legal do evento, foi a interação dos participantes.

Eu palestrei em conjunto com Luciano José, nossa palestra ficou meio “cortada” porque precisamos parar no meio para André Furtado realizar a palestra dele via Live Meeting, ele tinha um horário mais apertado do que nós.

Vou colocar apenas algumas fotos aqui, porque o post está ficando grande, mas, vocês podem acompanhar melhor como foi o evento direto no endereço: http://celulaspe.blogspot.com/

Além do meu passeio pelas Universidades e Faculdades daqui outras pequenas atividades me tomaram tempo, juntamente com a minha graduação e meu trabalho, como as reuniões com o pessoal da POLI.NET (célula acadêmica Microsoft da UPE) e a ajuda dada a alguns grupos de usuários interessados em iniciar células sobre XNA (como no caso da FIR).

Gostaria de deixar registrado o meu muito obrigado a todos os que participaram da minha jornada, tanto aos que ja estão comigo a algum tempo, como aos que me conheceram recentemente. Agradeço também a todos os MSPs de Pernambuco e ao pessoal do Sharpshooters por terem ajudado com o ECAPE.

Bom, por hoje é só, qualquer coisa entrem em contato, abraço.

Novidades do XNA 3-0 :-)

Faz um tempinho que não falo sobre XNA aqui no blog, mesmo tendo palestrado bastante sobre o assunto (estive passeando pela FG, FIR, voltei na FIR e estou agendado para na proxima segunda estar na UNICAP) estou acompanhando as novidades e passeando pelo blog do time de desenvolvimento do XNA eu achei uma notícia interessante sobre o lançamento do do game studio beta do 3.0, se quiser saber das novidades também, dê uma olhada no link.


abraço.

Engenharia de Software

Agora estou fazendo um "passeio" pela Engenharia de Software, porque fazer software não é suficiente, é preciso fazer com qualidade.

E por causa da minha mania de comprar livros, comprei o Engenharia de Software que é a referencia textual usada na universidade para essa cadeira, até agora estou gostando do livro, apesar de que o assunto requer muita literatura complementar.

Para deixar vocês com água na boca, ai vai uma questão do livro a minha resposta para ela, se quiser pode opinar a vontade :-)


Quais são as diferenças entre o desenvolvimento de um produto de software genérico e um produto de software sobre encomenda?

R:
Basicamente o software desenvolvido por encomenda é aquele que são encomendados por um determinado cliente. Esse tipo de software tem sua especificação controlada pelo cliente, desde o início do projeto até a suas alterações incluindo novos recursos e melhoria de funcionalidades.

Já o software genérico é aquele que tem sua especificação criada por alguma empresa de software para atender a uma determinada demanda de mercado, a empresa que fabrica o software tem o controle total sobre o projeto, desde a sua especificação até as novas versões do projeto.

abraço