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?
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.