Destilando

I don't believe in software architects!

2011-02-22T15:26:06Z

Let me guess... You would like to became a Software Architect, wouldn't you? I have seen a big push in the last inside software community by people who would like to became software architects.

A lot of them see this role as a step towards a career as a software developer. I would like to show that it is actually an illness in the software development environment.

Generally software architects aren't really software architects

There is big confusion in the market and in the software community about what the software architecture role is. I will not discuss all the ins and outs of the role but you can find a good explanation about it here, in a blog post of Elemar Júnior.

Nevertheless I can summarize by saying that the skills of a software architect are different from the skills of a developer, and it isn't a next step. Generally enterprises get the best developer and "promote" him to the position of software architect, this developer might never have seen an architectural pattern in his whole life. It clearly shows the existing confusion.

Much arrogance associated with the role exists

Many roles that have major importance and responsibility suffer from the evil of arrogance, so it is with presidents, professors and managers.

Because of the characteristic rigidity or impossible mutability of the architecture, architectural decisions are important decisions with a significant responsibilities attached.

It is always good to remember Dee Hock at this time: "Through the years, I have greatly feared and sought to keep at bay the four beasts that inevitably devour their keeper -- Ego, Envy, Avarice, and Ambition".

Anyone in a powerful role is vulnerable to the evil of arrogance. In Architecture Software particularly it looks like a inherent aspect of the job. Of course there is no rule and I am sure that there exists non-arrogant software architects, but all decentralization of power possible should be carried out.

Generalists worth more than Specialists

Also it is obvious that it is so much better to have a team of developers that can also do integration testing, than to have one or two testers in the team that will do all the integration testing of the team.

It is also clear that it is better to have a team of developers that is able to discuss possible architectures and find out an emergent solution than to have a specialist Software Architect that will make all the decisions.

Martin Fowler have already said the architects in ThoughtWorks works to increase the team's architecture skills than take their own decisions. It increase the team skills and solve the bottleneck problem. Have look:

                In many ways, the most important activity of  Architectus Oryzus is to mentor the development team, to raise
                their level so that they can take on more complex issues. Improving the development team’s ability gives an 
                architect much greater leverage than being the sole decision maker and thus running the risk of being an 
                architectural bottleneck. This leads to the satisfying rule of thumb that an architect’s value is inversely 
                proportional to the number of decisions he or she makes.
            

The real value of software architect skills

I have strong doubts about how useful some deliverables of the software architecture discipline are, some of them are documents and diagrams with a high level vision of the system. I believe more in principles and values that I believe can replace these deliverables like:

Effective communication between the teams is more important than documents and diagrams.
Architectural decisions should be done by teams, for me it is obvious that an emergent decision is more valuable than a decision made by only one holy holder of knowledge.(By the way I don't believe in holders of knowledge, Jedis, and their kind )

All the successful software projects that I know was made by passionate developers

Yes generally the good software releases with scalable and effective architecture that I know, are made by teams with passionate developers without a software architect, not because there aren't architectural decisions but because the architectural decisions are shared with the whole team and they can arrive at architectural solutions faster and better than a software architect.

I'm sure there are some really good architects and good initiatives within the agile software communities such as the emergent architecture and the evolution architecture, but in my experience they are people who I don't believe, and I think this centralized model is more likely to fail than the decentralized model.

Software architects are really needed in enterprises where 80% of the programmers are cowboy programmers using the true XGH. These enterprises will have quality problems anyway, but it is better that the architectural decisions are made by someone who really knows what he/she is doing. In this case and in an immature market they are "a necessary evil", if you don't have a team of passionate programmers at least have a software architect who will be able to define a reasonable solution.

Why should I refactor if refactoring is a waste?

2010-05-27T22:43:35Z

This is my first post (of a sequence of 3) about refactoring. I want to demystify some points in refactoring that are not evident in the software community.

The first step is to understand what is refactor. Put simply refactoring is everything that you do on code that becomes easier to understand and doesn't increase features or performance. This means if I change the code to ...

process faster
work in more cases
do something new
work as multi-threading
fix some bug
internationalizate the system
And bla bla bla that changes an external behavior or performance

You are not doing refactoring, sorry if I disappointed you, but this isn't a refactoring. But if you are doing changes in the code that allow your code to be easier to understand, probably this is refactoring, for example:

rename a method to a name more meaningful
split a big complex method in various small simple methods
create a class to replace some code that are redundant in the code
move a redundant field in all sub classes to a super class
and bla bla bla that become the code easier to understand

But second Lean, "anything you do that does not add value from the customer perspective is waste". When I'm doing some refactoring I'm not adding value to the software therefore this is a waste.

So why should I refactor if refactoring is a waste?

I understand that this is not easy to accept, but I have three reasons that can make refactoring payable.

1) Become more productive

So I think if you are reading from the begin of post until now you have already understood that refactoring is only "become the code easier to understand".

And ok, but how important is it to understand the code?

This is a old question on Software Engineering, there are many studies about this question, you can find some information here, here, here, here and here. However I want to highlight a study conducted by Microsoft Research, where we can find the following conclusion.

					Understanding the rationale behind code is the biggest problem for developers. When trying to understand a piece of code, developers turn first to the code itself and, when that fails, to their social network.
				

Therefore we can see that understanding code is one of the most important tasks in software development. Given that maybe If you spend less time to understand the code, you would be more productive. In other words when you spend 15 minutes to understand the code it is more productivity to fix bugs and write new features, than in a code that you have to spend some hours and after that you still not sure about what is happening.

2) Become faster to respond to changes

Refactoring will drive you to get a better software design, after all a software with a good design is a software easier to understand. With a good design your software is more flexible to changes.

3) Change the enterprise culture to acquire mastery

Did you ever hear "a winning team does not change" or "if it's not broken don't fix it"? This is a real obstacle to master, because the real master will not be satisfied with "the code works", the master always wants to be better, and this kind of resigned mind does not exists for the real masters and with refactoring should mess in working code, refactoring is this become something that works more clean, expressive and elegant.

So If you are not interested in productivity, respond to changes and mastering professional culture I think that you can have serious problems with your enterprise.

Addendum 1

Despite the refactoring being considered a waste, there are some kinds of waste that are classified as necessary wastes. Refactoring is an necessary waste example, you can find more information about that in "Refactoring is a Necessary Waste" and "Learning to See Waste in New Product Development".

Voltando a atividade... But with some news!

2010-04-10T19:08:59Z

Faz muito tempo que não posto nada por aqui, isso porque cerca de 1 mês atrás me mudei para Dublin na Irlanda (Sim, a terra da Guinness), pretendo ficar aqui por um ano se tudo der certo.

Vim para a Irlanda para aprender a me comunicar (ouvir/falar/escrever/ler) na língua inglesa DE VERDADE, por tanto a partir de now I will write all my posts in English, so I can practice more (If you find some grammar error, please notify me; I'm sure I will miss a lot).

I am studing in a english school in the center of Dublin called CES (Centre of English Studies), I think this is an excellent school and I've easily seen the quality difference between anothers schools in Dublin. My course is only for 6 months and the another 6 months not are defined yet.

The contact with people from others countries is a really nice experience. I'm knowing frenchs, indonesian, italians, belgians, saudi arabians, germans, spanish, south koreans and who can't miss: Irish people. I'm traveling for some beautiful places here in Ireland. So I've uploaded my photos in Picasa at this address.

Now I'm looking for a job in Dublin. I've did some interviews with success and now I'm waiting for replys. About the technology user groups I've found some communities here like Ruby Ireland and ALT.NET Dublin.

So I will try to keep this blog updated, to comment relavant things and news!

Diagnóstico do Nível de Excelência Comunicativa Nas Organizações

2010-03-01T19:34:53Z

Acabei de ler o relatório final de pesquisa de pós-doutorado da Professora Maria Schuler da ECA USP sobre o Diagnóstico do Nível de Excelência Comunicativa nas Organizações. O relatório fala sobre muita coisa interessante, mas vou dar destaque para o tema principal da pesquisa: Os Níveis de Excelência Comunicativa nas Organizações.

Em palavras simples a excelência comunicativa nas organizações é o melhor estágio de comunicação que se possa ter. E como ela é um resultado dos indivíduos que formam organização para se alcançá-la é preciso compreender a Excelência Humana nas organizações.

A Excelência Humana é uma analise mais aprofundada das pesquisas sobre o desenvolvimento humano. Um famoso psicólogo chamado Abraham Maslow, propôs uma hierarquia de necessidade, onde as necessidades do nível mais baixo precisam ser satisfeita para antes se ter consciência das necessidades dos níveis mais altos. Representada pela imagem abaixo.

O relatório de pós-doutorado explora cada nível como uma dimensão transdiciplinar onde existe uma análise holística de várias disciplinas em convergência. Assim deixa a visão de nível de necessidade para o conceito de dimensão transdiciplinar, onde alguns níveis são re-estruturados e profundamente analisados.

Esta análise de cada nova dimensão ocorre levando em consideração quatro elementos: o indivíduo, a organização, o processo de aprendizagem organizacional e o desenvolvimento da comunicação organizacional.

Neste post vou citar apenas os aspectos da organização, pois acho interessante analisar o conceito da agilidade neste elemento. Segue abaixo o diagrama dos níveis de Excelência Humana.

Física: é a dimensão onde a organização está como foco em recursos materiais, todas as decisões tomadas são em metas de curto prazo de rápido retorno financeiro.

Emocional: é a dimensão onde a organização começa a enxergar que não trabalhar com recursos e sim com pessoas, que estas pessoas têm emoções e o foco não está em evitar emoções e sim ter pessoas que sabem administrar suas emoções e utilizá-las de forma produtiva, estabelecendo relações de confiança e ética.

Mental: é a dimensão onde a organização começa a criar reais preocupações com sobrevivência onde entram processos de planejamento diário, os fluxos começam a ser racionais, lógicos, calculáveis, previsíveis. E as decisões começam a ser menos centralizadas envolvendo um número mais de colaboradores.

Afetiva: é a dimensão onde a organização integra o maior número de colaboradores ao sucesso compartilhando os benefícios de forma justa e generosa, também cria ambientes colaborativos, de forma a despertar uma consciência coletiva nos colaboradores.

Expressiva: é a dimensão onde a organização atingiu seus objetivos materiais e neste momento a ética começa a ser incorporada na natureza da organização valores com transparência, legitimidade e justiça. Citando SCHULER: “Nesse momento do desenvolvimento, a preocupação com a justiça dos atos transcende as normas estabelecidas ou as relações de castigo ou premiação”.

Visionária: é a dimensão onde a organização reconhece que os colaboradores que já são respeitados, tratados e de forma diferenciada desde a transcendência do nível afetivo, agora não são mais vistos como um par de mãos, mas como pessoas que possuem cérebros e idéias. Agora a organização precisa que estes sejam criativos, para sobrevivência, resolução de problemas, inovação e descoberta de conhecimento.

Integradora: é a dimensão onde a organização e colaboradores alinham missão, visão, vocações e o sentido de trabalhar; nesta dimensão o objetivo é criar um grupo unido, consciente de sua responsabilidade com a sociedade e o meio ambiente. Neste ponto cada decisão de cada colaborador reverbera os valores e a missão da empresa.

Bem o relatório é muito maior que este post, e eu fiz resumo porco muito simplificado de apenas um dos elementos estudados no trabalho, aconselho fortemente ler o trabalho disponível aqui, principalmente às analises em relação ao elemento: O Indivíduo.

Agora peço que preste atenção a dimensão mental, observem as palavras “processos de planejamento diário”, “fluxos calculáveis e previsíveis”, “decisões menos centralizadas” e “fluxos racionais”, isso lembra alguma coisa? Para mim lembra muito forte a idéias de agilidade.

Interessante ressaltar que a pessoa que escreveu sobre a dimensão metal nem sabia o que era Agilidade, entre tanto citou algumas características ágeis nesta dimensão, relacionadas no quadro abaixo.

Dimensão Mental	Agilidade
Processos de planejamento diário	Não sei de diariamente, vai depender do seu negócio, mas isso está muito próximo a “Responder a mudanças”
Fluxos racionais	Meio vago o termo, mas entendo como deixar de fazer a coisa da forma mecânica e entregar aquilo que agrega valor: “Software funcionando”, através de fluxos mais enxutos
Decisões menos centralizadas	Isso traz fortemente o princípio “As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.”
Fluxos calculáveis e previsíveis	Vejo isso perto da agilidade quando assumimos que o processo é empírico, tornamos as coisas realmente mais calculáveis e previsíveis com Sistema Kanban.

Entendo que para conseguir aplicar um método ágil é imprescindível que a organização já tenha passado pelos níveis: Físico e Emocional. Isso explica a dificuldade da adoção de práticas ágeis em algumas organizações, pois estas organizações não estão realmente preparadas para transcender para a dimensão mental. Por isso é muito importante entender para quem você está vendendo agilidade.

A agilidade é a dimensão onde a organização consegue ter atitudes mais racionais. Como podemos ver no diagrama existem dimensões acima da Mental e que vejo exemplos como a Semco, a Toyota e a iniciativa na Visa, onde existe algo muito maior que os princípios e valores da agilidade.

Eu não sei o que está acima da agilidade, mas sei que ainda estamos no meio do caminho.

Observação 1

A versão que eu divulguei aqui é uma versão reduzida publicada pela Metodista, assim que tiver a versão oficial diponibilizo aqui no blog.

A diferença entre ciências da computação e sistemas de informação

2009-11-28T00:50:00Z

Estive esta semana do Coding Dojo no IME-USP, junto com Hugo Corbucci e Mariana Bravo. Resolvemos fazer o problema Poker-Hand em Ruby, que consiste em: dado duas mãos de poker o software precisa dizer quem ganha.

O Hugo sugeriu que começássemos o programa pela Classe PokerHand, e depois fossemos programando as cartas, os naipes e assim por diante. A ideia se resume em criar toda a infra-estrutura para o programa antes de começar a implementar o núcleo (que seriam as regras do Poker) do mesmo.

Sugeri que não fizéssemos isso, mas que começássemos pela classe PokerGame (que mais tarde virou PokerRules), pois desta forma começaríamos descrevendo as regras, atacando o núcleo do problema primeiro e trazendo uma abordagem mais orientada ao domínio do problema.

Isso gerou algumas discussões, mas resolvemos tentar o que eu havia sugerido, e então implementamos todas as regras na classe PokerGame, assim esta classe já sabia dizer que “dois pares” é menor que “um trio”, que “Flush” é menor que um “Full House” e assim por diante.

Depois aplicamos os mesmos princípios às cartas e depois aos naipes, assim já tínhamos uma classe que sabia toda a regra do Poker e que tinha todo o conhecimento necessário para fazer os desempates.

Fomos para o PokerMatcher, esta classe tinha por objetivo reconhecer que uma determinada PokerHand era um “Flush” se tivesse uma sequência de números nas cinco cartas da mão.

Começamos o PokerMatcher, não criamos uma PokerHand, dissemos que uma PokerHand é um list de cinco cartas, isso é discutível, mas enfim optamos por isso. Implementamos a PokerMatcher até reconhecer “um par”.

E na retrospectiva eles me mostraram uma outra solução para o problema, que surgiu naturalmente em um outro dojo que eles fizeram. Percebi que esta outra abordagem se apresenta diferente, quando começa-se implementando as cartas e depois a mão até chegarmos ao seguinte ponto:

poker_hand1 > poker_hand2

Neste ponto, eles pensaram em atribuir um sistema de pontuação para cada uma das mãos onde baseado em um mapa de hexadecimal, cada dígito do número hexadecimal equivale a uma das jogadas de poker ordenado da direita para esquerda. O quadro abaixo ilustra esta forma:

Enquanto eles pensaram em criar uma fórmula matemática para pontuar cada uma das mãos, eu pensei em não pontuar mas descrever as regras um uma classe e criar um matcher para avaliar quem vence.

Acredito que nenhuma das soluções está certa e nenhuma das soluções está errada, mas que ambas possuem vantagens e desvantagens e que uma das causas que corroboraram nestas diferentes abordagens foi devido as distintas formações acadêmicas dos participantes do dojo.

Eu faço Sistemas de Informação, e eles fizeram Ciências da Computação. O curso de ciências da computação é um curso muito mais matemático do que curso de sistemas informação, pode-se observar pelas grades dos cursos. Segue abaixo um comparativo simplificado:

Está em CC mas não em SI	Está em SI mas não em CC
Física I	Computação Orientada a Objetos
Física II	Análise, Projeto e Interface Humano-Computador
Introdução à Probabilidade e à Estatística II	Fundamentos de Sistemas de Informação
Noções de Probabilidade e Processos Estocásticos	Contabilidade para Computação
Cálculo Diferencial e Integral III	Laboratório de Bases de Dados
Cálculo Diferencial e Integral IV	Introdução à Administração para Computação
Álgebra II	Arquitetura de Computadores
Métodos Numéricos da Álgebra Linear	Inteligência Artificial
Métodos Formais em Programação	Redes de Computadores
Análise de Algoritmos	Prática e Gerenciamento de Projetos
Algoritmos em Grafos	Economia para Computação
Conceitos Fundamentais de Linguagens de Programação	Empreendedores em Informática

Para eles foi natural a utilização de um mapa hexadecimal para pontuar a mão de poker, enquanto para mim esta ideia nem passou pela minha cabeça, pois não fazia o menor sentido pontuar a mão, e sim fazer um matcher com as regras do jogo. O interessante foi a experiência de ver a diferença dos raciocínios.

Este tipo de discussão é o que, para mim, mais agrega valor em uma sessão de Coding Dojo. Sempre devemos tentar conhecer novos mindsets, e quanto mais diferente, melhor. Pois quanto mais opções você conhecer para resolver um problema, mais bem preparado você estará para resolver o mesmo.

Adendo 1

Se no seu caso você ainda estiver escolhendo qual curso deseja fazer, e está em dúvida em ciências da computação ou sistemas de informação, pense no que você quer ser quando concluir a faculdade. Teoricamente ciências da computação prepara melhores programadores e cientistas, enquanto sistemas de informação prepara melhores analistas e engenheiros.

O mais importante é entender que não existe um curso melhor que o outro é tudo uma questão de objetivos.

Adendo 2

Se quiser dar uma olhada no código fonte do dojo está disponível aqui.