Complexidade é Custo

Desenvolver software profissionalmente, em um ambiente onde a finalidade é lucro, implica em ampliar ganhos e/ou reduzir custos.

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:

PRODUTIVIDADE = DESEMPENHO / EMPENHO

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. Este artigo menciona seu favorito a preços super baixos. Escolha entre entrega no mesmo dia, entrega drive-up ou retirada do pedido.

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

PRODUTIVIDADE = DESEMPENHO / EMPENHO

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:

CUSTO TOTAL = CUSTO PARA DESENVOLVER + CUSTO PARA MANTER

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.

Capa: Alice Pasqual