Keep Learning » Opinião

Modularity on Rails

Lucas Húngaro — Fri, 02 Mar 2012 01:06:06 +0000

Following my last article I’d like to elaborate on my opinions.

First, let’s review some things:

Yes, I know you can deactivate a lot of the bundled stuff in Rails; that doesn’t solve any of the issues.
Yes, I’m aware of Railties; It’s nice, well built, a good step forward; still doesn’t solve any of the isses.
Most of the people who reacted badly to my article (and @merbist‘s one) pointed out that, to use and understand Rails’ “modularity” you’re supposed to buy a book; I don’t think it should be necessary (nothing against the book, it’s very good)

The issues I pointed out converge to one thing: modularity isn’t configurability. Yeah, I can edit my default generated Rails app and remove all sorts of things, including using some hackish code to remove middlewares from its stack. This isn’t modularity on the application-level.

I know that Rails’s internals are more modular on Rails 3 than they’ve ever been. I’ve saw Jose Valim’s talk about how they’ve applied SOLID principles to achieve that, it’s really nice (read the slides if you can, it pays off). I’m not talking about that. I’d like to emphasize that I’m talking about modularity at the application level, not at internal code level.

Here’s an example (hypothetical context, of course):

$ rails new my_app # generates a lean app (not a Sinatra-style app, a Rails app without the unneeded stuff)
 
... # days after
 
# Hmmm, I need to send e-mails!
$ cd my_app
$ rails add actionmailer # adds and installs actionmailer, generates the boilerplate needed
 
# Hmmm, I need to speed up my assets load time!
$ rails add rails-assets-pipeline

Modular. Apps. Things I can incrementally build upon. Now, mailer should probably be there by default, but you get the idea.

These gems would be separated from Rails core. I really don’t care if a “full” Rails app ends up installing 100 gems as long as I’m in control of that and can start with way less.

What’s the advantages?

Easier to learn: beginners will have a better experience since they can learn the framework gradually;
Still powerful: that doesn’t force you to dumb it down, as many suggest. Modular apps suit the needs of novices and experienced developers as well;
Goodbye clutter and unneeded code: the framework will only load the code I need. Boot time will be decreased as well as memory consumption. Yes, I know that if you deactivate something today, most of the code won’t be loaded, which gets us to…
Less code to understand: it will be easier to contribute to the framework as it will have way less code and I can gradually dig in. I can contribute with the core without stumbling into the assets pipeline, for example.

Well, I could elaborate more on that, but it’s the main idea. Rails’ internals are way better, yes, and that’s awesome. But the framework still lags behind on many things I think should receive priority instead of adding built-in support for SASS, CoffeeScript and things like that. I’m currently taking a look at Rails’ codebase to see how I can fit these ideas in. I hope to have some pull requests ready soon. If you’re interested in helping, please contact me.

Rails has entered the framework death spiral

Lucas Húngaro — Thu, 01 Mar 2012 04:44:52 +0000

I usually write here in Brazilian Portuguese but this post is written in English in the hope of getting some useful attention and discussion going on (yes, wishful thinking).

Before we start this, let’s make some things clear. When I criticize Rails there’s two common reactions:

The Lovers:

“OMG, DHH and the Core Team are awesome, they know what’s better for you, stop crying!”
“Well, stop using Rails and create something better!”
“You should not criticize the tool that pays your bills!”

The Haters:

“Yes! Yes! Let’s burn these motherfuckers!”

Let me be totally clear here: Rails is very useful and I like it a lot (although I used to like it way more). Otherwise I would just dismiss it and don’t even bother trying to get some attention to the issues I’ll describe. I respect the work and effort of so many people that keep the framework going fixing bugs and adding features. You should too, it’s not a walk in the park and very few people actually get some time to do this kind of work. A special mention goes to Aaron Patterson (@tenderlove), a guy who relentlessly keeps cleaning up the mess that Rails’ codebase has become while still keeping his humility (sadly, a rare trait in our community).

Some days ago, when talking with a friend, he said “Rails has entered the framework death spiral – it’s now adding features for feature-sake”. I agree. The “Rails is opinionated software” idea is clearly lost as it’s trying to embrace everything and has turned into a playground for some people (not the entire team, to be clear) instead of a framework that shapes the way web applications are created (that paradigm is shifting and meanwhile Rails is messing around with CoffeeScript and SASS).

One example of this “playground theory”? Releasing a piece of crap like the assets pipeline, clearly rushed and so fucked up that it makes me think if it’s the worse thing I ever had to use to build software, occupying a honorable spot besides the Struts framework, ASP and JavaServer Faces.

The main problem, in my humble opinion, is: Rails has turned into bloatware. I see the problem from two angles: as a potential contributor and as a user of the framework.

As a contributor

Rails has so many things included by default now that the code is really big. I tried to understand it some time ago and got quickly frustrated by the massive amount of coupled code and features that distract you from the main workflow of the framework. Yes, I could probably just get some ticket and solve a bug, but I like to understand the whole before going around throwing code like crazy to get some commits in. OSS activists will probably bash me for this, calling me lazy, but it’s the way I work, sorry.

The solution? Well, my suggestion is this: the rails gem should contain only the core, the request processing cycle and hooks for the other parts to hang in (ORMs, template engines, other gems in general). It already has this in some form, a framework called Railties, but all the things that hook into it are still in the same codebase, divided in a few other gems.

The asset pipeline is a main offender here and the easiest example to bring to the surface. This thing should *really* be into its own gem and out of Rails. It could be included in Rails’ default Gemfile, I don’t care, but please do not throw more code into the mess. I won’t even start the discussion about the quality of the pipeline per se, but I digress. If you want the default approach, the one the Core Team chose, just generate a full app and install de default gems. Otherwise we could have a lean application generator that remove all the uneeded dependencies without hacks. Better yet if that one could be the default.

If my memory isn’t failing me, I believe Merb did things this way. Besides lessening the burden on contributors it should force people to write decoupled code, something the Rails Core Team has been improving on for some time now, by the way.

Yes, I know Rails included extra things like ActionMailer and ActiveRecord from the beginning and they’re independent gems. As I said before, I’m fine with default choices, but I also think that Rails’ starting point should be a lean and simple mini-stack that could be easily incremented as the user needs it to be.

As a user

People who are experienced with Rails tend to forget that beginners do exist. Most of the so called “Railers” I know see themselves as a kind of superior being surfing the waves of awesomeness, forgetting that legacy must be supported and new people will try Rails. Funny thing is that the developers that use Rails as a mere tool (what it is) see this issue clearly, while people that see it as a religious cult dismiss it.

The first issue is legacy. Rails completely ignore this (as is common with frameworks in so called “non-enterprise” ecosystems) and makes no effort to support people that work with legacy code. The community itself fails hard at this, as we don’t even talk about that as we should. Think about how rare it is to see a talk about legacy applications on conferences in contrast to the plethora of talks about new features/libraries or how you should be writing your code. We fail hard here.

The second issue is that, as of today, Rails is incredibly hard for beginners to learn and use effectively. It’s slow, has a freaking unbelievable amount of dependencies right of the bat (this can be normal down the road, not by default), it’s cumbersome to set up (don’t you love some gem version hell?), it’s not quick to get up and running anymore. I usually joke that the “15 minutes blog” today should be called “the 1 hour and 30 minutes blog”. That’s not to mention the big disparity between the official literature and documentation (“the DHH way”) and the way real Rails apps are developed.

EDIT: to be fair, I installed the latest Rails and generated a new app. No version hell this time, hurray! The last three times I did it, it was a nightmare. Things are still slow though. You can generage your application with “rails new my_app –skip-sprockets –skip-test-unit” to drop the generation time from ~2 minutes to about ~30 seconds. Other flags like –skip-active-record and –skip-javascript are available to bypass some default dependencies.

It’s hard for people who already knows Rails to imagine how it is to begin with the framework today. I’ve seen beginners trying it and it was ugly. Think about how many unrelated things someone has to go through to understand a simple “Hello World” in a default Rails application today.

What got me interested in Rails was the “batteries included” approach, yes. But there was a thin line and, to me, that line has been crossed. Rails went past the line of “including everything you need for a quick start” to “including everything the Core Team thinks you need to build a gigantic web application following every techniques they find appropriate”. Yes, I know it’s best practice to minify my JavaScript but I’m a grow up, let me do it the way I want without clogging up the framework with a lot of useless code (yes, I can deactivate it, but it’s still useless since I won’t use it and it will slow my boot time and bloat the framework code, hence the idea of splitting Rails into more gems and do not install them by default nor include them in the same codebase).

Conclusion

The Rails framework should really get trimmed down. Non-fundamental trinket should be separated and, maybe, we could have two application generators: a “lean” (maybe just ActionPack and Railties, something like that) one and a “full” one. That way it would be a lot easier to grasp the framework code and contribute while allowing newcomers to taste the goodies gradually, learning instead of being drowned into a lot of concerns that really doesn’t relate to the core of developing a well built application.

EDIT: Yes, the title of the article is harsh and I recognize it does not reflect what I wanted to suggest here. It was wrong and tabloid style. It was chosen out of frustration, which shouldn’t be a reason to do it. The intention of the article is to spark a good discussion, not to be alarmist and accusatory, which the title makes it sound like.

[Rant] Menos guerrinhas. Mais princípios

Lucas Húngaro — Fri, 29 Apr 2011 16:51:47 +0000

Aviso: o post não é lá a coisa mais coesa do mundo mas, bem, é um rant, então estou despejando pensamentos aqui.

É algo muito bom que cada desenvolvedor possua sua “stack” preferida de ferramentas. O apreço por esse conjunto leva à dedicação e ao domínio do mesmo.

Entre nós, que orgulhosamente nos categorizamos como “trabalhadores do conhecimento”, creio que, apesar desse apreço à priori não causar prejuízo, trocar de conjunto de ferramentas deveria ser muito fácil (e uma habilidade desejável) já que o que importa é a transformação do conhecimento da forma bruta (dados) à forma desejada (informação), independente do que foi utilizado para isso. É claro que há sempre a curva de aprendizado numa troca dessas: uma nova linguagem, nova DSL/API etc, mas os fundamentos e princípios se mantém.

Nerds, assim como toda pessoa imersa numa sociedade consumista, se definem pelo que consomem e utilizam. Isso é algo bem comum atualmente e vai desde roupas até computadores, editores de texto, smartphones e, pasmem, à p**** da biblioteca que o cara usa pra fazer parsing de XML. Algo que tornou-se muito comum, principalmente com a facilidade que existe para que cada um publique seus pensamentos (blogs, Twitter e afins), é que ocorram “guerras” sobre esse tipo de coisa, já que, em nossa mente, criticar uma coisa que consumo é praticamente criticar a mim e meu modo de viver.

Entre desenvolvedores isso é bem visível. Além das guerrinhas entre comunidades (.NET x Java, Ruby x Python etc) há também as guerras intra-comunidade, em que escolhas de ferramentas são motivo para disputas de ego intermináveis. O cenário, em geral, mostra uma galera que gosta da ferramenta X e acha que, por isso, a ferramenta Y é uma merda inútil e o pessoal que gosta da ferramenta Y achando o mesmo da ferramenta X.

Passemos a um exemplo num contexto diferente para que pré-disposições não afetem nossas conclusões. Imagine que Gordon Ramsay irá a sua casa para fazer o jantar. Ele não vai levar as facas, panelas e demais utensílios que usa em seu dia-a-dia. Vai utilizar apenas o que tem em sua casa. Dias depois você irá a casa dele e utilizará todos os utensílios profissionais à disposição. Bom, a não ser que você seja um anônimo chef de primeira categoria, sabemos quem irá preparar o melhor jantar, não? (sem piadinhas hein! )

Mais um. Quem será que toca melhor: Steve Vai com uma guitarra Giannini de 500 reais ou você com as guitarras ultra-caras dele?

Onde está o conhecimento? Na ferramenta ou no profissional?

Algo bizarro que acontece é ver pessoas que deveriam ter bons conhecimentos sobre lógica confundindo argumento com preferência. Dizer que você prefere X porque acha mais bonito ou mais legal é só sua preferência, não é um argumento para diminuir as alternativas. Chega de “RSpec é mais bonito e moderno, então Test::Unit sucks!” e vice-versa (exemplo aleatório, sem flames por favor).

BREAKING NEWS: se você não sabe patavinas sobre design de código orientado a objeto e uma meia dúzia de princípios básicos, escrever testes em RSpec não vai fazer com que você escreva código melhor do que escrevendo com Test::Unit. Aliás, é bem capaz de piorar as coisas, mas isso é conversa pra outro post.

Em linhas mais práticas, pouco importa para o interessado na informação se ela é processada em PHP ou Ruby, se é formatada em ERB ou HAML ou se está armazenada em MySQL ou PostgreSQL. A ferramenta “certa” é a que faz o trabalho. Sempre há muita discussão sobre isso de “ferramenta certa” e, a não ser que seja algo obviamente errado como usar o Rails pra fazer uma aplicação desktop com controles nativos, o que sempre acaba entrando em jogo é preferência, gosto, estética e etc. Novamente, isso simplesmente não serve como evidência de que algo é superior ou inferior.

“Mas eu sou mais produtivo com X do que com Y!”
“Olha só como meu código fica mais limpo com Z do que com N!”

É, amiguinho. Pra você. Assim como tem muita gente que acredita em divindades criadoras e muita gente que não. Muita gente que acha carros da Porsche bonitos e muita gente que os acha toscos e que os carros da Toyota sim são lindos. Daí a dizer que algum é melhor ou pior é um longo caminho (e, na minha visão, um caminho inexistente).

Pois bem. Por isso creio que, como comunidade, devemos mudar um pouco nosso foco. Tudo bem falar sobre ferramentas, é algo saudável desde que feito com bom senso. Com argumentos, fatos, contexto e harmonia. Não com guerrinhas bobas sobre gosto pessoal e como ~~seu pau é maior que o dos outros~~ sua gem preferida é a mais fodolenta do OMNIverso. É bom para conhecermos alternativas e evoluirmos. Se todo mundo se prendesse ao atual e rejeitasse as novidades, ainda estaríamos perfurando cartões. Enfim, é preciso foco em coisas que realmente fazem a diferença na qualidade. Foco em fundamentos e princípios.

Estatísticas do DataLucas mostram que, a cada dois dias, surgem dezenas de posts falando sobre alguma gem que é a coisa mais maravilhosa já inventada desde o ~~carro voador~~ Toddynho (e que prova que todo o resto é uma merda!), sobre uma miríade de workflows para o VCS da moda, sobre porque a minha biblioteca é mais foda que a sua, sobre como o Agile morreu e, claro, como ele ainda está vivo e funciona muito bem sim senhor!

Legal, todo mundo tem uma opinião sobre o que prefere e sobre o que não gosta. Muito bom, ótimo, sensacional. Mas e o que é imutável? Aquilo que determina qualidade independente do meio utilizado? Já postei bastante essa frase, mas sempre gosto de relembrar:

As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.

— Ralph Waldo Emerson

Ainda não achei frase que se encaixe mais com meu pensamento sobre desenvolvimento de software. Seja no nível gerencial ou técnico, dominar métodos (ferramentas) ignorando princípios com certeza leva à problema. Manjar de todas as cerimônias e artefatos das metodologias ágeis não vai produzir software de qualidade magicamente. Entender seus princípios, mesmo que você não aplique toda a parafernalha cerimonial, com certeza trará efeitos positivos.

Então fica a pergunta: onde estão os posts e talks sobre princípios? Vamos falar sobre coisas como SOLID (não, não é um besteirol acadêmico), acoplamento, coesão, testes que realmente especificam comportamento, trade-offs arquiteturais e outras questões importantes?

Tentarei fazer a minha parte nisso. Ano passado na RubyConf parte da minha apresentação falou sobre princípios (e outra sobre ferramentas ) e penso em continuar com essa temática tanto no blog quanto em futuras apresentações. Gostaria muito que a comunidade valorizasse mais esse tipo de discussão (wishful thinking…).

Já fiz muito dessas guerrinhas, não sou inocente, mas aprendi a valorizar a base, principalmente abrindo a mente (olha a piadinha!) e dando chances à ferramentas diferentes e, com isso, percebendo que em nossa profissão, felizmente, há vários meios eficientes para atingir os resultados desejados.

And… here comes the flames?

PS: se você é do contra e vai bater o pézinho dizendo que preferência e estética são evidências qualitativas, pode desistir e vaza.

Leitura recomendada: “A Little Knowledge is a Dangerous Thing“

Uma frase para complementar o último post…

Lucas Húngaro — Thu, 16 Dec 2010 01:28:29 +0000

As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.

— Ralph Waldo Emerson

Substitua “método” por “linguagem” e isso resume muito bem o meu pensamento.

O poliglotismo “cria” bons desenvolvedores?

Lucas Húngaro — Wed, 15 Dec 2010 14:53:37 +0000

Não.

Vejo algumas concepções falaciosas em nossa comunidade que há muito já foram superadas em outras profissões. Uma delas é que dominar mais ferramentas torna o profissional melhor. Será mesmo?

Estudamos tanto lógica para aprender a programar e nos esquecemos de uma armadilha lógica básica: confundir causa e efeito com correlação. Ou, pior, caímos na falácia do Efeito pela Causa e acabamos invertendo as coisas. O fato é que quanto melhor o profissional, mais ferramentas ele vai querer explorar.

Explico: um bom desenvolvedor vai querer aprender mais linguagens para aumentar seu repertório de soluções. Um péssimo desenvolvedor pode aprender 20247232 linguagens e o máximo que conseguirá é ser um péssimo desenvolvedor em 20247232 linguagens. Causas: dedicação e proficiência. Efeito (um deles): desejo de expandir o conhecimento. E, assim, temos um ciclo virtuoso.

Não me entenda mal: eu acredito que conhecer várias linguagens é algo muito positivo. Mas também vejo acontecer um tipo de “pressão social” por isso, como se não pudessem haver preferências e predileções. É o mesmo tipo de pressão social que rola se você falar que não gosta de “The Beatles”. As pessoas vão te olhar feio, pode ter certeza (os caras foram – ou ainda são – muito fodas e mudaram muita coisa, só não fazem o meu estilo, então por favor não arranquem meu couro – e olha eu com medo da pressão).

Em geral, quando eu digo que acho legal conhecer e brincar com várias linguagens mas que prefiro, de longe, desenvolver com Ruby, muita gente já “olha torto”. Veja bem, eu não quero dizer que vou escolher Ruby pra tudo for desenvolver – isso é ser cego. O que eu quero dizer é: se eu estiver num “empate técnico” durante a escolha de linguagem, vou preferir Ruby sempre (hoje, pois o futuro não se sabe, não é?). Além disso, quase sempre que eu for programar algo por diversão, vai ser nessa linguagem.

Acredito que há ótimos desenvolvedores monoglotas (que logo sentem a necessidade de expandir seu vocabulário) e péssimos desenvolvedores poliglotas. E vice-versa. Não é um requisito, é uma opção. Como diz aquela famosa frase: “Você pode escrever Fortran em qualquer linguagem”.

Android e iOS são realmente competidores?

Lucas Húngaro — Mon, 13 Dec 2010 21:24:40 +0000

Acredito que não. Pelo menos, não diretamente.

Escrevi um pouco sobre isso aqui: Oceano Azul vs Oceano Vermelho: Android vs iOS (meu Tumblr, onde passarei a concentar os textos não relacionados à programação)

O que você está construindo?

Lucas Húngaro — Sat, 21 Aug 2010 16:41:35 +0000

O ser humano é um construtor. Nós, desenvolvedores de software, independente de formação ou posição, temos fome de construir. O que queremos é construir coisas a partir de nossas ideias, botar à prova nosso conhecimento e, dessa forma, adquirir maturidade, experiência e mais conhecimento.

Vejo dois comportamentos profissionais comuns que podem prejudicar muito isso:

Quero ser promovido: aquela pessoa que acredita que deve se dedicar 100% à agradar aos seus superiores. Dessa forma ela conseguirá “evoluir” profissionalmente até chegar à tão sonhada liberdade profissional/financeira.
Eu não ligo: para esta pessoa, “é apenas um trabalho”. Ela não vai se aprimorar, simplesmente porque não vê necessidade. Em geral, não constrói nada, pois não acredita estar fazendo algo em benefício próprio.

No primeiro caso, a dita “liberdade” nunca será alcançada pois, na verdade, ela não existe. Pouquíssimas pessoas (se existir alguma) possuem a “verdadeira” liberdade: estar completamente livre de qualquer restrição de tempo, espaço e recursos. Isto é: dinheiro infinito e possibilidade de tempo e localização para estar onde quiser no momento que quiser, independente de qualquer fator externo. Isto é utópico.

A liberdade está em cada um – basta se sentir livre para ser livre – e é bem possível atingir isso nessa sociedade louca movida à sacrifícios em nome da tal “vida profissional”: basta não participar da loucura.

No segundo comportamento, vai ficar sempre um vazio pois, independente de ser por trabalho ou por diversão, temos essa necessidade intrínseca de construir: daí o fato de pessoa nenhuma, mesmo com riqueza “infinita”, conseguir ficar absolutamente sem fazer nada por muito tempo. A maioria de nós precisa trabalhar pra se sustentar, então temos de encontrar meios para conciliar isso com a satisfação por criar.

No final das contas, é sim “apenas” um trabalho: o seu trabalho, a sua criação (seja em troca de dinheiro ou não). Evite errar pelo excesso ou pela falta. Deve ser algo a se construir e se orgulhar, não um empecilho para seu bem estar. Se esse for o caso, hora de se movimentar para mudar: o que você está construindo?

Comprometa-se consigo mesmo.

Lucas Húngaro — Wed, 28 Apr 2010 21:28:04 +0000

Uma frase que ouço com frequência é: “não se comprometa com trabalho feito para outros, apenas com um negócio próprio”. Bom, tenho que dizer que isso é um perfeito discurso de perdedor. Primeiro porque, em geral, as pessoas que falam isso estão trabalhando para outras. Segundo porque elas não tem coragem para assumir riscos e começar um negócio próprio.

Isso costuma ser trazido muito à tona em conversas com amigos e conhecidos pois prefiro trabalhar em startups em oposição à empresas grandes e tradicionais. De alguma forma, startups estão ligadas a profissionais mais comprometidos, o que nem sempre é verdade, e muitas usam esse “status” para exigir longas e estafantes jornadas de trabalho. Ninguém deve se comprometer com esse tipo de vida, seja a empresa uma startup ou não.

Não consigo me imaginar passando oito horas por dia fazendo algo com que eu não tenha comprometimento e não acredite que vai dar certo. E isso não é exclusivo à startups: esse tipo de atitude é necessária esteja você trabalhando em uma startup com mais três pessoas, em uma corporação gigantesca ou no seu próprio negócio.

Você iniciaria uma empresa para fazer algo em que não acredita? Penso que não. Então por que em um emprego “normal” isso seria diferente? Fazendo uma conta bem básica, são cento e sessenta horas por mês, durante trezentos e sessenta meses (equivalente a trinta anos), o que dá seis anos e meio continuamente fazendo algo que você não dá a mínima.

Enquanto você não inicia seu próprio empreendimento (talvez nunca), a solução é encarar o “trabalho para os outros” como seu empreendimento. Afinal, é isso mesmo o que ele é. O lucro (ou prejuízo) final pode não ficar na sua mão, mas o trabalho que você realizou e a sua satisfação com ele não dependem disso.

Se você não consegue enxergar isso como possível, é um ótimo sinal de que você deve parar de se lamentar e iniciar seu empreendimento. Comprometa-se consigo mesmo, independente do fato de, no momento, você ter um chefe ou ser o chefe.

Desenvolvedor, arquiteto, programador, engenheiro…

Lucas Húngaro — Wed, 04 Nov 2009 13:16:53 +0000

É realmente necessário ter equipes de arquitetura separadas de equipes de desenvolvimento? Essa pergunta é muito antiga e cada um tem uma resposta. Pra mim, não. Mas vamos pensar mais sobre isso.

Em primeiro lugar, o que é um arquiteto de software? É um desenvolvedor com muito conhecimento e experiência (minha resposta)? É um profissional diferente, especificamente treinado para a arquitetura de sistemas? É alguém que possui algum “dom” especial?

O cargo de “Arquiteto de Software” como empregado hoje na indústria do software é mais uma herança ruim da comparação entre desenvolvimento de software e construção civil. Nesta última, o arquiteto faz o projeto mas, em geral, não suja as mãos no cimento. O ponto é: arquitetar um sistema de software é ou não é fundamentalmente diferente de construir software, isto é, programá-lo, testá-lo e mantê-lo? Não. Existem algumas diferenças e algumas preocupações diferentes mas é impossível dissociar as atividades no nível em que é feito em outras áreas.

Um fato interessante é que apenas empresas grandes, com orçamentos folgados (que, em geral, desperdiçam tempo e dinheiro com futilidades e becos sem saída) costumam oferecer o cargo de arquiteto de software. Eles geralmente ficam em equipes de arquitetura, longe das equipes que “sujam” as mãos no código no dia-a-dia. Ora, isso, por si só, cria as Torres de Marfim e uma certa animosidade latente entre as diferentes equipes – que deveriam trabalhar em conjunto todos os dias.

Não faz sentido (e não é eficiente) ter equipes de arquitetura separadas, sem contato direto e constante com as equipes de desenvolvimento. Também não faz sentido empregar arquitetos de software que só planejam e não participam da execução diariamente.

Usando a já batida metáfora do desenvolvimento de software como jardinagem é fácil perceber que estamos longe do processo utilizado, por exemplo, na construção civil ou na indústria automobilística. Não é possível projetar todo o software com antecedência, como um prédio ou um carro, comprar a matéria-prima, contratar os operários e implementá-lo praticamente sem desvios. O projeto é o software e o software é o projeto.

Podemos, sim, ter um plano geral, um conjunto de guias e processos a serem seguidos, interfaces definidas, padrões e tudo mais, mas é preciso adaptação rápida à mudança. Na criação (e não construção, isso é importante) de um jardim, uma planta pode não se desenvolver por um entre vários fatores. Na criação de software, uma especificação da equipe de arquitetura pode não se encaixar nas necessidades do projeto.

Se houver uma “equipe de arquitetura” como uma entidade especial, separada, perde-se muito tempo para reagir às mudanças. Se os arquitetos são do tipo que se acha bom demais pra se sujar na programação as conseqüências são ainda piores – em primeiro lugar porque eles não tem noção da realidade do projeto enquanto fazem os planos e, em segundo, porque tendem a resistir à mudanças no que consideram um plano perfeito.

Se insistíssemos em utilizar a metáfora da construção civil, podemos comparar todo o ciclo de desenvolvimento de software com o ciclo de arquitetura e projeto de um edifício, excluindo sua construção. O desenvolvimento de software é uma atividade criativa, não “mecânica”.

Um desenvolvedor de software que não se atenta à arquitetura, que não tenta melhorar nos fundamentos básicos necessários ao entendimento do software como um todo, não passa de um programador – um mero codificador, facilmente substituível.

Um arquiteto de software que não programa, não se envolve com o dia-a-dia da produção de software e não se interessa pelos outros aspectos da disciplina, não passa de um “masturbador mental de software“. Daí para o que os americanos chamam de “Death by PowerPoint” leva um piscar de olhos.

Sim, é necessário que tenhamos a figura do “líder técnico”, aquele desenvolvedor com bastante experiência e jogo de cintura, que já viu e já fez de tudo na área. Ele, inclusive, pode ter o cargo formal de arquiteto de software. O que não pode acontecer é que ele seja um profissional isolado em uma esfera de cristal, um “deus” criando o que ele pensa ser adequado, dando ordens e ignorando eventuais questionamentos de sua intocável arquitetura. Isso é tudo o que um time de verdade não precisa.

Em resumo, um bom desenvolvedor é também um bom arquiteto. E um bom programador. E um bom qualquer coisa que seja necessária para criar software consistentemente.

Seu chefe é incompetente? A ciência explica!

Lucas Húngaro — Thu, 03 Sep 2009 19:28:33 +0000

Pesquisas feitas na Universidade de Catania, na Itália, mostram que, quanto mais promoções, mais incompetente é o profissional. A pesquisa foi feita a partir do chamado Princípio de Peter, formulado pelo psicólogo canadense Laurence J. Peter, com a seguinte frase (original, em inglês): “Every new member in a hierarchical organization climbs the hierarchy until he/she reaches his/her level of maximum incompetence”.

A explicação é simples: no sistema de promoção por mérito, pessoas muito boas em dada especialidade são promovidas para outras áreas, para as quais podem ser menos aptas (claro, isso só ocorre quando a promoção leva o profissional a uma área em que suas habilidades atuais não são fundamentais). Dessa forma, cair nas garras do Princípio de Peter torna-se inevitável, levando a empresa a uma perda geral de eficiência ao longo do tempo.

A solução, segundo os cientistas, é reservar 50% das promoções para os piores profissionais da empresa – a chance de que eles “se encontrem” nos cargos aos quais são promovidos é muito maior.

Que desenvolvedor de software nunca topou com esse tipo de problema? Aquele cara, ótimo desenvolvedor, acaba sendo promovido à gerente (e aceita, seja pela grana, pelo status ou por falta de opção) e é simplesmente um zero à esquerda na função. É claro que isso acontece em qualquer área, mas é nesta em que eu tenho experiência.

Podemos tirar duas lições disso:

Se, por ser um ótimo desenvolvedor, você for agraciado com uma promoção para outra área, pense duas vezes antes de aceitar – isso pode significar o fim da sua carreira como profissional competente. Se a empresa não lhe der opção (é bem comum que só se consiga um aumento aceitando uma promoção-bomba dessas), procure outro lugar – quando você realmente é competente, escolhas não faltam.
Se você se tornar um empreendedor, primeiro busque ajuda especializada caso não se sinta à vontade com as tarefas necessárias nesse seu “novo cargo”. Você pode ser um ótimo designer com uma ótima ideia, mas isso não quer dizer que será um bom empresário. Além disso, pense bem na política de promoção que vai utilizar se a empresa for bem sucedida. Um exemplo: pode ser muito mais satisfatório recompensar os bons funcionários com melhorias salariais do que promovê-los a cargos para os quais eles não possuem aptidão.