Gladiator Features

This is a common pattern here in Hekima. We avoid implementing some feature, saying it is not going to be used often enough to justify its implementation costs. “We’ll just manually set this in the database when needed”, or “If anyone asks for this, we can export it from the database manually”, we would say.

Then, we would have to repeat this manual task more often than not. “Let’s make a script, it’ll make the whole process easier”, we would say.

Then, running this script would become too time consuming, and we would finally bake the feature directly into our app, so the user would have direct access to it. Lots of times, we would deem a feature unworthy of our development time, and it would slowly but surely crawl its way into the app.

We named those features Gladiator Features. The manual task that became a script. The script that became a feature. The feature that defined a product. That is how the Gladiator quote goes, right? No?

Gladiator (2000)

Anyway, we used to think that when this happened, it was a flaw in our planning, and that we should have been able to predict it. But in the Gladiator movie, not every slave became a gladiator, and in the development world, not every manual task becomes a full-fledged feature.

If we chose to implement and develop every feature requested by users, we’d probably find that most of those features wouldn’t be actually used at all, and we would have spent precious time into something with no return of investment. By only implementing what is really needed, we are building a lean product, and spending our development time where it really matters.

A Gladiator Feature isn’t necessarily a flaw in the planning stage of an app. It is more like a lazy evaluation of the worth of a feature, and that is perfectly OK.

Tags: agile, scrum, scripts, features, mvp, gladiator, and The manual task that became a script. The script that became a feature. The feature that defined a product.

Related Posts

Brincando com dados: Prevendo ganhadores do Oscar de 2017

No último post post analisamos as features do Rotten Tomatoes. Agora, vamos juntar todas as features relativas as principais premiações com as geradas utilizando os valores do Rotten Tomatoes e tentar prever quais serão os ganhadores dos Oscar de “Melhor Filme”, “Melhor Atriz” e “Melhor Ator”.

Brincando com dados: Análise do Oscar - Rotten Tomatoes

Finalmente chegamos àquela época do ano. Podemos chamá-la de “carnaval dos cinéfilos”, ou simplesmente de “aquela época em sabemos que a Meryl Streep será indicada”. A época das premiações mais importantes do mundo do cinema. Então vamos aproveitar essa época e fazer uma análise sobre as notas no Rotten Tomatoes dos indicados ao Oscar de melhor filme.

Prevendo evasão (churning) usando scikit-learn

Prevendo evasão de clientes em python utilizando scikit-learn.

Análise de sobrevivência (Survival Analysis)

Pequeno estudo sobre Análise de sobreviência que é um ramo da estatística que analisa tempos até ao acontecimento de determinado evento.

Brincando com dados: Descobrindo tópicos em livros com LDA

Brincando com dados: Vencedores do Oscar Parte 2

Na parte 2 vamos analisar os dados dos indicados ao prêmio de melhor filme dos últimos 15 anos e tentar prever o ganhador do ano de 2016.

Brincando com dados: Vencedores do Oscar Parte 1

O objetivo desses posts intitulados "Brincando com os dados" é dar exemplos de como importar, limpar e analisar dados. Nesse primeiro exemplo iremos importar no MongoDB os dados do IMDb dos filmes indicados a categoria de melhor filme do Oscar.

Projetando um ambiente inovador

Como criar um ambiente que estimule inovação