Tá bom, tá bom. Estava tudo muito parádo por aqui. Parado não, a melhor definição é coma. Isso, o coding4food estava em coma. Mas era um coma induzido. Estive um tempo envolvido com alguns projetos muito importantes (jogando video-game, vendo TV, lendo alguns livros, engordando, … ).

Mas hoje o coding4food saiu do coma graças a um e-mail que perambulou entre os departamentos da empresa onde trabalho. O texto falava sobre a regulamentação da área de TI. E mais uma vez, o famigerado projeto de lei 7109/06 era alvo de novas discussões. O projeto já é antigo, porém vem a tona de tempos em tempos, como um span-highlander que insiste em renascer entre fóruns e afins.

O Sr. Bonifácio Andrada já foi responsável por longas threads no guj e as opniões sobre o assunto são as mais diversas: a SBC sempre foi contra, porém o CCT aprovou o projeto em março de 2008. Tem gente que não pode nem ouvir no assunto, outros acham que um sindicato pode significar um aumento de salário rápido e fácil, quase que milagroso, como sugerido pelo e-mail abaixo:

Pessoal, até que enfim, ao que tudo parece agora sai a lei que regulamenta nossa profissão. Isso significa um sindicato próprio (não esses fantasmas que cobram de nós sem nem sabermos ao menos quem são), piso salarial, garantias e deveres definidos, etc.

O link para a notificação de entrada na pauta de Senado é, acompanhem o andamento do projeto através do cadastro no site:
http://www.senado.gov.br/sf/ atividade/Materia/Detalhes. asp?p_cod_mate=82918

Por favor, perdi alguma coisa ou tem gente achando que vai ganhar um aumento de salário com a simples criação de um conselho ou sindicato ? Provavelmente o Sr. Bonifácio Andrada conhece do mercado de TI o mesmo que o Sr. Expedíto Júnior: ABSOLUTAMENTE NÁDA.

Sério. Por vezes procurei argumentos ou justificativas que me fizessem acreditar que este projeto de lei não fosse mais uma “politicagem” sem pé nem cabeça. Não acredito mais em analistas de sistemas, porque iria acreditar nisso ?! Então vamos lá, como nem a ACM, nem a SBC encontrou motivos para impor alguma regulamentação em nossa área, vamos deixar que os profissionais lá de Brasília o façam.

O que posso dizer sobre isso é apenas repetir o Akita:

Será que um músico diplomado é melhor que um Villa Lobos? Será que um pintor diplomado é melhor do que uma Tarsila do Amaral? Será que um escritor formado será melhor do que Machado de Assis? Será que o Washington Olivetto é um grande publicitário porque é formado? Ah, não, ele nunca concluiu o curso de publicidade da FAAP.

Grandes programadores não são formados. Grandes programadores se formam.

Não entendo porque algumas pessoas tem uma necessidade de proteção de algum órgão, sindicato ou conselho para se sentirem mais seguras. Pra mim, a competência é o que prevalece e não o diploma. Não sou contra o curso superior. Ir a faculdade foi umas das melhores escolhas que já fiz na minha vida. Mas conheço ótimos profissionais hoje, que não foram alunos tão brilhantes assim. Isso porque os bons profissionais não param apenas com o canudo. Estão sempre estudando, se aperfeiçoando, lendo, indo um pouco mais além. Para estes profissionais, o mercado sempre terá espaço. Tenho a impressão de quem é a favor da regulamentação, precisa de uma “garantia legal” para manter o seu emprego. Se este for o caso, acho que o funcionarismo público, seria o mais indicado.

Como daqui pra frente apenas os analistas de sistemas poderão desenvolver software, vamos excluir todos os engenheiros, matemáticos, físicos, administradores, filósofos que estão fazendo programas de computador por esse país a fóra. Afinal, eles não tem competência para fazer isso.
Sendo assim, alguém que é a favor dessa lei poderia me dizer se também está disposto a apenas comprar software desenvolvido por analistas de sistemas “licenciados” ? (… porque aposto que seu computador está infestado de “programinhas” desenvolvidos por adolescentes.)
Aliás, excluir engenheiros da área de TI seria no mínimo, cômico. As ciências da computação por anos vem tentando (sem muito sucesso, diga-se de passagem) aplicar técnicas de engenharia no desenvolvimento de software. Na verdade, a maioria das metodologias utilizadas hoje estão com um pé na engenheria. Mas isso não importa, vamos mandar todo esse pessoal para faculdade, porque eles não conhecem náda de computação.

Como iríamos tratar os projetos open-source? Com certeza não poderíamos mais utilizar muitos desses softwares, porque esses projetos são desenvolvidos por profissionais de todo o mundo, de todas as idades, todas as áreas e formações. Não, não poderíamos utilizar um software desse. Quem iria nos garantir que foi desenvolvido apenas por analistas de sistemas formados ? Com certeza, não poderíamos correr esse risco.

“Mas tem muita gente sem formação, roubando a vaga de profissional com curso superior!!!”

Essa é a maior das falácias. Seria hilário se não fosse triste. Se o profissional não for competente, não são seus diplomas ou certificados que irão lhe salvar. A competencia é o que prevalece. Ninguém rouba vága de ninguém. Apenas alguns profissioanis são mais competentes no que fazem, do que os outros, simples assim.

Alguém já conheceu algum engenheiro que se sentisse mais seguro pelo CREA ?!
Alguém já viu a OAB, CREA, CRA ou algum outro conselho convocar uma greve ? Fico me perguntando por que não ?
O MEC já existe a muito tempo… mas impediu a abertura indiscriminada de pseudo-faculdades e o comércio de diplomas pela internet ? Porque que será ?

A reserva de mercado, como proposto por esse projeto, é andar para trás, e a ACM já vem falando nisso a muito tempo:

ACM is opposed to the licensing of software engineers at this time
because ACM believes it is premature and would not be effective at
addressing the problems of software quality and reliability.
ACM is, however, committed to solving the software quality problem
by promoting research and development, by developing a core body of
knowledge for software engineering, and by identifying standards of
practice.

Is ACM against licensing software engineers?
Yes. For legal reasons, the only way to be a licensed software
engineer is to become a PE. As described in the Safety-Critical
report (see www.acm.org/serving/ se_policy/safety_critical.pdf), several
topics on which all prospective PEs are tested, such as fluid mechanics
and thermodynamics, are beyond the scope of software engineering.
Mastering these topics could detract from the study of more relevant
areas.
In addition, a software engineering license would be interpreted as an
authoritative statement that the licensed engineer is capable of producing
software systems of consistent reliability, dependability, and
usability. The ACM Council concluded that our state of knowledge and
practice is too immature to give such assurances.

Is ACM against software engineering being viewed as a profession?
No. ACM believes it is important to foster the emergence of a true IT profession,
not just software engineering. A field does not need licensing to be a
profession.

A área de TI já não sofre o suficiente com escassez de profissionais no mercado ?!
A CLT já não impõe burocracia e carga tributária suficientes sobre empregadores e empregados nesse país ?!
O mercado de TI no Brasil já não tem problemas o suficiente ?!
Afinal, quem serão os verdadeiros beneficiados com esta regulamentação ?

Alguns dias atrás, me vi numa discussão com alguns colegas, sobre funções, atividades e cargos dentro de uma empresa. Apensar desse assunto ainda ser bem confuso em TI, a maioria soube descrever suas atividades diárias como programadores. Porém, essa descrição não foi obtida tão facilmente quando nos perguntamos: Afinal de contas, o que um “Analista de Sistemas” faz ?

Alguns me falaram que o analista de sistemas é um profissional com mais experiência, com perfil investigativo, que deve fazer a análise dos requisitos e modelar uma solução. Outros disseram que analista de sistema não devem “perder”  tempo com detalhes sobre linguagem ou tecnologia, porque “análise” de sistemas deve ser feita em alto nível, a.k.a UML. Escutei também alguns comentários clássicos: analista de sistemas necessariamente não precisa saber programar, precisa apenas conhecer UML e algum editor de texto. ( “analistas de sitemas não precisam saber programar…”. Com certeza essa merece estar nas próximas falácias da programação, parte ll … hehe )

Sobre esse assunto, tenho que dizer que concordo com Barry Hawkins: a super divisão de trabalho no desenvolvimento de software, foi umas das piores experiências da indústria de software nos últimos anos.

One of the most widespread tragedies in the practice of software development has been the tendency of corporate culture to over-compartmentalize the activities of software development. In the upper echelon of the artificial hierarchy of task separation sits the software architect. Sequestered away from the disturbing din of real life within the company, these persons are liberated from the mundane, in order that they may orchestrate plans that set in motion the work of many, unfettered by such things as domain knowledge and implementation constraints.
Know this; the only people who belong in white towers are the captured princesses of fairy tales, and even then it was not of their volition. Partitioning the activity of design away from implementation destroys the call-and-response cycle between design and implementation. The relevance of your work is directly related to how engaged you are in the domain.
- Barry Hawkins.

Estou convencido, que a separação das atividades de design e programação deveria ser qualificada como um anti-pattern do desenvolvimento de software. O waterfall já vem mostrando por anos, que essa abordagem é um erro.

Porque é necessário criar um cargo especial para atividades, que deveriam ser de responsabilidade do programador ?! Análise, design, programação e arquitetura são atividades e não cargos. Nós, como programadores, precisamos vestir “chapéus” diferentes dentro de um projeto.

Quando questionamos requisitos, buscamos informações de nossos usuários, organizamos e priorizamos tarefas, estamos vestindo nosso chapéu de analista e gerente de projetos. Quando estamos codificando, nos preocupando com manutenabilidade, performance e com a correta aplicação de patterns, estamos vestindo nosso chapéu de programador e projetista. Ao escolhermos por um framework, por uma API, estamos com certeza tomando decisões de arquitetura.
Não quero dizer aqui, que todo programador dever ser um  Macgyver em TI. Mas tenho certeza, que se você é programador, é bem provável que você precise colocar à prova diariamente suas habilidades como programador, analista, arquiteto ou gerente.

A maioria dos programadores passam anos querendo se tornar analista de sistemas, e quando conseguem, descobrem que como programadores, já desempenhavam atividades de análise a muito tempo. Além do mais, achar que um monte de diagramas UML podem modelar um sistema inteiro sem programar uma linha de código, não é algo muito inteligente. Analistas, arquitetos, projetistas, seja lá como for o nome que deram para ele, mas esse cara precisa saber programar -  If you design it, you should be able to code it - Mike Brown:

When designing the architecture for your project, you need to have a feel for what amount of effort is necessary to implement the various elements of your design. The easiest way to have the knowledge of the effort that a specific design element will take is to have developed it before.

Don’t use a pattern in your design that you haven’t personally implemented before. Don’t rely on a framework that you haven’t coded against before. Don’t use a server that you haven’t configured before. If your architecture depends on design elements that you haven’t personally used, there are a number of negative side effects. Mike Brown

Muitas empresas de TI estão procurando “achatar” hierarquias, procurando manter profissionais mais qualificados, com conhecimentos multidisciplinares e que possam atuar em diversos papéis diferentes. Que possam programar, tomar decisões de arquitetura ou conversar com usuários se for necessário. Por mais que muita gente ainda pense o contrário: Profissionais competentes e equipes motivadas são fundamentais em qualquer empresa.

E mesmo que os “Analistas de Sistemas” ainda existam para enfeitar alguns crachás corporativos ou anúncios de RH, eu já deixei de acreditar neles já faz algum tempo …

Esse mês deixei a DTS Consulting, empresa pela qual prestava serviços ao HSBC Bank Brasil desde o ano passado. Não, não …. não vou me aposentar. Aliás, a tão sonhada aposentadoria está cada vez mais longe, e na verdade, todo ano precisa ser postergada … hehe…

Gostaria de agradecer à todo o pessoal da DTS e do HSBC que aguentaram bravamente as minhas lamúrias por todos esses meses à fio, e que apesar de toda minha chatice, nunca desistiram de mim!!!
Para vocês todos , apenas posso desejar muito sucesso !!!… hehe…

Desde a semana passada faço parte da equipe de integração da Global Village Telecom - GVT, através da eWave do Brasil. Tenho muito ainda para apreender, e vi na GVT uma oportunidade para trabalhar com tecnologias e ferramentas ainda desconhecidas para mim. Em alguns projetos, estão sendo desenvolvidas algumas idéias do SCRUM, o que deixa o trabalho um pouco mais dinâmico. E nem preciso dizer, que tenho uma certa simpatia por metodologias ágeis !!!

Acho que muita coisa está por vir, nos próximos sprints, vamos ver o que acontece… hehe…