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 …

Desde que trabalho com desenvolvimento de software, venho observado a necessidade das empresas em gerar documentação. Esforços são feitos e muito tempo é investido na tentativa de criar e manter documentos de arquitetura (SAD – Software Architecture Document) em projetos de todos os tipos e tamanhos. E ao mesmo tempo, não é incomum que arquitetos de software, não saibam justificar por que a maioria das suas atividades diárias, acabam se resumindo na atualização de diagramas. E nem saibam dizer quem é o maior interessado em toda essa documentação.
Mas enfim, qual é a relação entre a documentação e o sucesso de um projeto ? Segundo Scott Ambler, nenhuma.

There is no solid relationship between project success and writing comprehensive documentation, and in fact it is more likely that the more documentation that you write the greater the chance of project failure.  Have you ever seen a project team write a comprehensive requirements document, get it signed off by your stakeholders, only to have the developers build something else?  Or the team actually builds to spec, only to have your stakeholders say that’s not really what they wanted?  Or the team delivers late or over budget, even though everything looked good most of the way through the project?  Have you ever seen a team create a comprehensive architecture model, have it reviewed and accepted by really smart people, only to see the architecture fail in practice anyway?  Or the developers simply ignore the model and then go off and build it the way that they want to?  Have you seen all this happen under the guise of management oversight, without management realizing what was happening until long after it occurred?
Scott W. Ambler

Na minha opnião, o que mais influenciou este comportamento, é um antigo conceito herdado da indústria de software e do waterfall model: o BRUF approach. Essa técnica é comprovadamente inviável e de fato não conheço nenhuma bibliografia séria, que recomende essa prática. A idéia de que seria possível levantar todos os requisitos de um sistema antes de gerar qualquer código executável, fez com que muitas empresas
ficassem por anos gerando documentos de todos os tipos e formatos.
Penso que documentar pontos fundamentais e use cases essenciais de um sistema não é um problema. O problema ocorre quando a documentação se torna o foco principal do projeto e as pessoas envolvidas tornam-se prisioneiras dos templates e da burocracia.
Muitos gerentes de TI, quando colocados em discussões como estas, refutam de formas diferentes, mas mas maioria se baseia no mesmo paradigma:

“Então vamos sair programando, sem nenhuma análise prévia ?!?!”

Não. A UML2 é uma ótima forma para investigar pontos críticos de um sistema, fazer avaliações de viabilidade de uma arquitetura ou comparar soluções para um determinado problema. E principalmente, a UML é uma fantástica linguagem de comunicação entre as equipes quando à utilizamos como UmlAsSktech. Alguns diagramas de iteração são muito úteis para expor idéias mais detalhadas numa reunião e para troca de informações entre arquitetos e programadores. Um diagrama mais simples, como de caso de uso, pode ser utilizado para demonstrar à stackholders e outros interessados no projeto, uma visão geral dos requisitos básicos de um sistema. Nestes casos, a abstração da UML é aceitável, já que preciso apenas de um overview sobre alguns pontos do meu sistema.

Na sua essência, a UML está relacionada com comunicação. E apesar de terem sido criadas várias ferramentas para geração de código fonte a partir de diagramas, acredito que a indústria de software ainda não conseguiu resultados satisfatórios com MDA e qualquer outra técnica de forward engineering. Ainda não vi nenhuma ferramenta que pudesse gerar código fonte aceitável em termos de qualidade a partir da UML. E acho que estamos bem longe disso por enquanto. Bons programadores, SEMPRE serão fundamentais.
Mas por que ? Porque a UML, apesar de ter evoluído muito desde a sua primeira versão, não está preparada para modelar TODOS os detalhes, comportamentos e funcionalidades que podem ser escritas no código fonte.

Além disso, outro ponto crítico sobre a supervalorização a UML, reside no simples fato de que ainda não  existe uma forma de validar UML. Como posso validar se um requisito está detalhado em um diagrama de sequência ? Como posso testar se uma regra de negócio do meu domínio foi corretamente “modelada” ?
UML não é executável e por isso não tenho como validar se um design é bom ou ruim. Todas as regras de negócio estarão implementadas no codigo fonte, e é código fonte, executável, que pode ser validado. É o código fonte executável, que poderei submeter a testes em TDD. Então por que não modelar em código ?

That, yes, but more. The source code is also the ONLY document in whatever collection you may have that is guaranteed to reflect reality exactly. As such, it is the only design document that is known to be true. The thoughts, dreams, and fantasies of the designer are only real insofar as they are in the code. The pictures in the reams of UML are only veridical insofar as they are in the code. The source code is the design in a way that no other document can claim. One other thought: maybe gloss isn’t in the writing, maybe it’s in the reading.
Ron Jeffries

Código fonte bem escrito é o melhor design e documentação que um programador pode fornecer, bem mais rico em detalhes do que qualquer diagrama UML. O problema é que a maioria dos desenvolvedores não encaram código fonte com uma forma de documentação e nem sequer levam em consideração que programação também é uma atividade de design. A preocupação com a clareza e simplicidade do código, a correta aplicação de patterns e a prática de refactoring também são atividades de design sob responsabilidade do programador. Estas práticas provavelmente produzirão a documentação mais atualizada e precisa do sistema. É claro, que muito código fonte que se encontra por aí, não é legível, e sequer pode ser encarado como documentação. Mas tenho certeza que isso esteja mais relacionado com a competência do programador, do que com o fato de que código fonte não possa servir de documentação. E de qualquer forma, digitadores de luxo nunca foram a melhor opção.

Vejo que na maioria dos casos, o simples é a melhor opção. Muitas vezes, papel, caneta e alguns rabiscos podem representar da melhor forma possível o comportamento de uma funcionalidade ou regra negocial. Geralmente uma boa conversa entre a equipe, pode economizar muitas horas de trabalho em ferramentas de modelagem e ganhar muito tempo de programação no projeto.
A UML é uma boa pedida, para promover comunição entre equipes, na validação de arquiteturas ou na verificação de algum ponto mais complexo do sistema. Mas o faça, quando a equipe sentir essa necessidade ou quando a complexidade do projeto exigir isso.
Modele em código fonte quando possível e cuide dele, faça do refactoring um hábito.
Não torne a geração de diagramas obrigatória para todos os projetos. Documente o necessário e corte as “gorduras”. Não burocratize demais. Não crie checklists demais. Não formalize em excesso.

E se ainda assim você optar em continuar documentando tudo. Pelo menos, economize papel e pense antes de imprimir. Porque afinal de contas, toda essa papelada vai servir pra que ?

Conversa vai, conversa vem, e esse assunto volta a ser tema de discussões no GUJ. Apesar de muito já ter sido dito sobre o assunto, é incrivel como muitos profissionais de TI ainda tem resistência em aceitar que algumas coisas simplesmente não funcionam, até mesmo quando os resultados destrasos da aplicação dessas práticas já estão muito bem documentados.

Com relação as fábricas de software e o modelo de produção em massa,  algumas questões chamam atenção:

1. Software não é um prédio, uma casa ou uma ponte.

A idéia de que se poderia, desenvolver software de qualidade, da mesma maneira como engenheiros constróem um prédio, ou uma ponte por exemplo, é no mínimo despropositada.
Um prédio é uma estrutura rígida, imutável e com certeza você não poderá fazer um refactoring na sua estrutura. Não podemos simplesmente adicionar mais salas, quartos ou janelas à um andar, sem que tenhamos impactos na estrutura da construção.

A construção de um prédio, é intuitivamente o resultado de atividades sequenciais interdependentes. Não sei como construir um prédio, nas não preciso ser mestre de obras ou engenheiro civil, para saber que preciso ter as paredes concluídas antes de partir para o telhado. Que preciso garantir que o fundamento da construção, terá resistência suficiente para aguentar o peso do cimento, aço, tijolos, etc. A engenharia consegue prever com precisão considerável,  antes do início da obra, quais o custos envolvidos num projeto.

Mas software não é assim. Desenvolvimento de software é muito mais empírio e artesanal. Muito mais humano do que as diferenciais e integrais que fazem com que um prédio fique de pé, imóvel durante anos.
A subdivisão enorme do trabalho e definição de fases distintas num enorme Waterfall,  é algo que funciona na construção civil, mas nunca obteve sucesso no desenvolvimento de software.

Segundo Craig Larman, é evidente o fracasso dessa abordagem:

There isn’t one simple answer to why the waterfall is so failure-prone, but it is strongly related to a key false assumption underlying many failed software projects that the specifications are predictable and stable and can be correctly defined at the start, with low change rates. This turns out to be far from accurate and a costly misunderstanding.
Applying UML and Patterns – Larman, Craig

As fábricas de software repetem os mesmos erros de 50 anos atrás: insistem em mensurar os projetos como um todo antes de iniciá-lo,  instalam metodologias burocráticas, utilizam métodos de gerenciamento inflexíveis, montam equipes enormes e dividem as atividades em fases , produzindo software como numa linha de montagem.

2. Desenvolvimento de software não é um commodity.

A maioria das fábricas de software, infelizmente, vendem horas. Horas de programadores, analistas de negócio, analistas de sistemas, testadores, arquitetos, etc.
Esse tipo de abordagem gera algumas situações bem interessantes: projetos atrasados, cronogramas imprecisos,  desinteresse pela qualidade do serviço, pouco comprometimento dos profissionais e principalmente muito custo para o cliente.
Na maioria das vezes, o cliente tem problemas e não sabe como resolvê-los,  e busca em empresas de tecnologia a soluçao dos seus problemas. Veja, não existe nada de errado em terceirização. É compreensível que uma empresa foque esforços no seu core business ao invés de contratar/capacitar profissionais de TI ensinando-os como programar.
Mas é fundamental que qualquer empresa conheça muito bem seus fornecedores, antes de contratar qualquer consultoria com CMMi 5.

3. Desenvolvimento de software é mais humano do que se possa imaginar.

One of the aims of traditional methodologies is to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manager. The individuals aren’t so important, only the roles are important. That way if you plan a project it doesn’t matter which analyst and which testers you get, just that you know how many you have so you know how the number of resources affects your plan.
But this raises a key question: are the people involved in software development replaceable parts?
The New Methodology – Fowler, Martin

Uma fábrica, por definição, ignora o fator humano no desenvolvimento de software, não levando em consideração a coisa mais importante: as pessoas. Geralmente são adotados inúmeros processos de qualidade CMM’S, CMMi’s, MPS.BR na tentativa de tornar as pessoas substituíveis. A maioria desses modelos de qualidade, definem detalhes inúmeros de processos, artefatos de entrada e saídas,  diagramas, checklists, templates de documentos, etc. Ninguém precisa conhecer do negócio do cliente apenas saber preenhcer os formulários. Ninguém precisa pensar em melhores soluções. Pois todas as soluções já estão pré-formatadas, bastando apenas ao profissional seguir religosamente os procedimentos pré-estabelecidos.

Programação é um processo criativo e que depende de soluções idealizadas e implementadas por pessoas. E o envolvimento destas é fundamental. Não é por acaso que empresas como Google, Yahoo, Flickr, Facebook fazem questão de anunciar publicamente fotos de seus escritórios cheios de puffs e sofás extravagantes, com pessoas trabalhando de bermuda e chinelo.

Bruce Eckel define a raiz de todos os problemas no desenvolvimento de software como sendo humanos:

We are in a young business. Primitive, really — we don’t know much about what works, and we keep thinking we’ve found the silver bullet that solves all problems. As a result, we go through these multi-year boom and bust cycles as new ideas come in, take off, exceed their grasp, then run out of steam. But some ideas seem to have staying power. For example, a lot of the ideas in agile methodologies seem to be making some real impacts in productivity and quality. This is because they focus more on the issues of people working together and less on technologies.

A man I’ve learned much from, Gerald Weinberg, wrote his first couple of books on the technology of  programming. Then he switched, and wrote or coauthored 50 more on the process of programming, and he is most famous for saying “no matter what they tell you, it’s always a people problem.”

Usually the things that make or break a project are process and people issues. The way that you work on a day-to-day basis. Who your architects are, who your managers are, and who you are working with on the programming team. How you communicate, and most importantly how you solve process and people problems when they come up. The fastest way to get stuck is to think that it’s all about the technology and to believe that you can ram your way through the other things. Those other things are the most likely ones to stop you cold.

As fábricas de software ainda colocam os processos acima das pessoas, numa tentativa de produzir sistemas independentes do intelecto humano. Como se isso, fosse possível.

Mas …

Felizmente existem pessoas que não pensam dessa forma. E muitas outras metodologias vem ganhando espaço no mercado. Acho que ainda estamos apreendendo a desenvolver software e muito ainda está por vir. Mas algumas empresas já perceberam que algo está errado. Por isso, acredito que o mercado sempre irá se ajustar, fazendo a seleção do que realmente é melhor, e condenando, empresas que visam apenas o curto prazo e lucro imediato.