Welcome back to the next installment of our weekly update in which we do something a bit odd for a vendor: expose holes in our product! Let’s be honest: nothing is perfect — and by discussing problems netTerrain users have encountered, we want to foster a collaborative environment, share some workarounds around common issues and — why not, poke a little fun at ourselves.
Features, schmeatures: we all want them, and it’s the first thing we usually look at when researching any type of software package (regardless of whether it’s a text editor or a Data Center Infrastructure Management (DCIM)) solution.
“Can it paint the kaboozle? Nice. Can it sizzle the bandabble? Great. Now, can it clone the patooty? What? It can’t do that? That’s a showstopper alright.”
It doesn’t matter if the product has 1000 features: someone will, always and without fail, want feature #1001. We all want our pet feature. Now, I am not dissing on features. Afterall, what’s a software without features? A single-line program that after execution just ends?
Philosophical dissertations aside, it’s true that a lot of the software in today’s world is bloated and suffers from ‘feature creep’ (heck, sometimes I feel ours has too many), but: in a way, features are what differentiate one software from another. We have to be careful, however, around which ones we decide to add.
This week’s complaint is a response to questions about how we select which features we add to netTerrain. A lot of our users want their pet feature and sometimes it is already in the roadmap, or about to come out, or in other cases it may take a long time to make it into the product or perhaps we will never include it. This may create some level of anxiety for our dear user, especially if they somehow expect it.
I hope we can agree on this: if our engineers added every single DCIM or OSP feature that is requested, we would grind to halt in a week. No further explanation necessary. So, how do we pick the features that will make it into the next netTerrain release?
Customers drive our product:I am not saying this to sound poetic, but simply because it’s the truth. When I look at all the functionality in netTerrain, whether it is for discovering the network, mapping the network, visualizing an IT infrastructure or dealing with DCIM capacity planning, virtually all features were driven by some sort of customer request.
These are the two main considerations we look at when evaluating a feature request:
1. Does the feature sing?
As I said, not all requests can make it into the product. Before we decide whether something qualifies to even make it into the roadmap, we must look at how that feature plays in the sandbox:
- Is it something that would be out of place in the overall GUI?
- Does it contradict some basic philosophy of the product?
- Is it counter to some design principle we abide to?
If the answer to any of those things is yes, then we toss it out. This is the first litmus test for a possible feature, regardless of how many customers request it.
Here is an example: we regularly get requests or questions regarding 3D views in DCIM. We are quite opinionated about it and unless we are talking about (true) computational fluid dynamics, we strongly believe that stuff has as much value as a spit in a bucket. To that end, when we get requests about 3D views, we politely explain that it is more likely that we change our name to ‘crapTerrain’ than add that feature and then we point them to this fun blog which serves as our manifesto against 3D views in DCIM.
In other words, whether it’s for network mapping, DCIM, or fiber plant, features added in netTerrain are not just some random assortment of requests that were coded on a first-in, first-out basis. They are all cohesive in some way as they are what makes up the product with a consistent look, feel, and set of features. Even if a specific feature is, say, more related to network discovery for instance, within the GUI and software framework — it has to sing.
2. How many customers are whining?
Alright, that sounds mean… we actually love it that our customers request things as it means they use netTerrain! However, features that appear repeatedly as requests from different customers tend to command our attention: the ones we hear the most or which have a special strategic value take precedence in the roadmap.
For example, let’s say you are a customer who desperately wants a feature and it’s not already being built in the roadmap. Does it mean you have to wait until more customers ask for that same thing and hope we decide to build it at some point? This process could take years…
Well, there is a way to still get that feature done, rather quickly. It’s with a purchase order!
Still, however, we do not treat this lightly though. The feature has to sing (as explained above) and it becomes available for all of netTerrain users.
All the other customers that did not pay for the feature still may get to enjoy it? Unfair? Maybe, but the alternative would imply that we maintain more than one version of netTerrain and/or the feature is not maintained and not compatible with future versions of netTerrain. That’s an absolute No-No. Not happening.
Now that you have a deeper understanding of how we work with new feature requests — what are you waiting for? Send us some requests through our customer portal and get those pet features ready!