Tem cuidado com os custos pequenos! Uma pequena fenda afunda grandes barcos.
Benjamin Franklin

Desenvolver software profissionalmente, em um ambiente onde a finalidade é lucro, implica em ampliar ganhos e/ou reduzir custos.
0
Considerações?x
Como arquitetos, o desafio é criar propostas de design que atendam os objetivos de negócio, atributos de qualidade e restrições, geralmente com o menor custo possível.

O resultado esperado é sempre “Ganhar mais” ou “Gastar menos”, de preferência “Ganhar mais gastando menos”! Terá melhores resultados quem conseguir entender bem essa relação:

Quanto maior a complexidade, maior o empenho. Logo, maior o impacto negativo sobre a produtividade.

Sobre Complexidade

No desenvolvimento de um sistema enfrentamos diferentes complexidades. Podemos classicá-las como:

  • Essencial – Aquela que não pode ser evitada.
  • Acidental – Aquela que “escolhemos” adicionar ao projeto.

Outra classifcação relevante para complexidade seria:

  • Domínio – Inerente ao problema de negócio que estamos tentando resolver
  • Solução Técnica – Com relação as técnicas e tecnologias (frameworks, ambientes operacionais, etc) que optamos por adotar
  • Legado – Soluções que precisamos continuar suportando, alheio a nossa vontade.

Embora não seja uma regra de ouro, podemos estabelecer duas relações entre as classificações que acabamos de propor:

  • Complexidade Essencial = Domínio
  • Complexidade Acidental = Solução Técnica + Legado

Em suma, geralmente, a única complexidade que geralmente não pode ser evitada, de forma alguma, é a complexidade do domínio. As demais, somente serão toleradas se forem indispensáveis para atender as demandas do domínio (pensando em disponibilidade e assertividade [entre outros atributos não funcionais acordados com o negócio])

A complexidade do domínio também é a única que o “negócio” entende.

Complexidade é Custo

Agora, proponho uma nova leitura. Vamos trocar a palavra complexidade, que usamos acima, por custo.

Logo, temos:

No desenvolvimento de um sistema enfrentamos diferentes complexidades custos. Podemos classicá-los como:

  • Essencial – Aquele que não pode ser evitado.
  • Acidental – Aquele que “escolhemos” adicionar ao projeto.

Outra classifcação para complexidade custos relevante seria:

  • Domínio – Inerente ao problema de negócio que estamos tentando resolver
  • Solução Técnica – Com relação as técnicas e tecnologias (frameworks, ambientes operacionais, etc) que optamos por adotar
  • Legado – Soluções que precisamos continuar suportando, alheio a nossa vontade.

Embora não seja uma regra de ouro, podemos estabelecer duas relações entre as classificações que acabamos de propor:

  • Complexidade Custo Essencial = Domínio
  • Complexidade Custo Acidental = Solução Técnica + Legado

Em suma, geralmente, a única complexidade o único custo que geralmente não pode ser evitado, de forma alguma, é a complexidade o custo do domínio. Os demais, somente serão tolerados se forem indispensáveis para atender as demandas do domínio (pensando em disponibilidade e assertividade [entre outros atributos não funcionais acordados com o negócio])

A complexidade O custo do domínio também é o único que o “negócio” entende.

Implicações da relação Complexidade e Custo

A única complexidade (ou custo) que o negócio entende e que, naturalmente, está disposto a pagar é a relacionada ao domínio. Não há muita sensibilização pela infraestrutura de nuvem, nem pela estratégia de persistência, nem sobre as estratégias de teste, nem com a integração com o banco de dados legado. Para o negócio, todas essas são questões acidentais – são custos que escolhemos e que deveriam ser evitados.

Voltemos a relação com a qual iniciei este post:

Terá maiores chances de êxito quem entender que as Complexidades/Custos Acidentais implicam em aumento do empenho e são um obstáculo à produtividade.

Como justificar complexidade/custo acidental

O custo total de um sistema pode ser descrito como:

Como desenvolvedores profissionais, buscando a produtividade, devemos tomar decisões visando reduzir o custo total empenhado.

Geralmente, há um trade-off entre o custo para desenvolver e para manter. Ou seja, quando optamos por uma estratégia que irá reduzir o custo de manutenção, aumentamos o custo de desenvolvimento. Quando optamos por uma estratégia que irá reduzir o custo de desenvolvimento, geralmente optamos por aumentar o custo de manutenção.

De forma empírica, geralmente é mais inteligente optar por reduzir o custo de manutenção para minimizar o custo total. Mas a resposta definitiva depende de cada caso.

Quando optarmos por adicionar complexidade a um projeto, precisamos verificar se haverá redução no custo para desenvolver ou para manter. Caso não haja nenhum ganho, será difícil justificar essa opção.

De qualquer forma, é sempre melhor reconhecer que estamos falando de custos e é dessa forma que devemos debater com (e sensibilizar) o negócio.

Por exemplo:

  • Testes reduzem o custo total significativamente, pois reduzem o custo de manutenção (embora podendo aumentar um pouco o custo de desenvolvimento)
  • Adotar o framework XPTO facilita a adoção de novas features, reduzindo o custo da manutenção
  • Um banco de dados NoSQL diminui as dificuldades para persistência de dados novos mais adaptados a novos cenários de negócio (manutenção mais baixa)

Concluindo

Desenvolvimento profissional é, em boa dose, a arte de escolher complexidades (custos) com eficiência. Todo custo para atender o domínio é bem atendido pelo negócio (e geralmente aceito). Todos os outros custos devem ser justificados com base no impacto para o custo total.

Lembre-se, recurso/funcionalidade/benefício não percebido pelo negócio, no final do dia, é só custo. Por definição, custos devem ser cortados.

Compartilhe este capítulo:

Compartilhe:

Comentários

Participe da construção deste capítulo deixando seu comentário:

Inscrever-se
Notify of
guest
0 Comentários
Feedbacks interativos
Ver todos os comentários

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mentorias

para arquitetos de software

Imersão, em grupo, supervisionada por Elemar Júnior, onde serão discutidos tópicos avançados de arquitetura de software, extraídos de cenários reais.

Consultoria e Assessoria em

Arquitetura de Software

EximiaCo oferece a alocação de um Arquiteto de Software em sua empresa para orientar seu time no uso das melhores práticas de arquitetura para projetar a evolução consistente de suas aplicações.

ElemarJúnior

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Podcast

Arquitetura de Software Online

55 51 9 9942 0609  |  me@elemarjr.com

+55 51 99942-0609 |  contato@eximia.co

+55 51 99942-0609  contato@eximia.co

0
Quero saber a sua opinião, deixe seu comentáriox
()
x