Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My team will regularly make code changes that break a unit or integration test for a feature hidden deep in the dark corners of our application.

When the test breaks there is a frequent question, "Who is even using this feature!?". We generally un-break the code and make the test pass because, as developers, we cannot determine if a feature is still in use and still needed.

How can my team and I effectively address obscure or seemingly strange features? I think what we want to know is if any customer is using them and if not can we remove the feature.

With several hundred users and the nature of our app it would be hard to put a logging or reporting feature in our app to phone home whenever a 'feature' is used. I think that makes this a management process rather than a technical process.

share|improve this question

closed as too broad by gnat, MichaelT, World Engineer Mar 17 at 14:15

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

7  
While this does not address your question directly (that's why I write it as a comment), I would take such findings with a grain of salt. From our experience - I work for a large e-commerce platform providing tons of features - it usually takes a good while for a feature to start being used. Also just because people don't use a feature, does not mean they don't need it. Maybe they don't use it because it's badly implemented (poor user experience and/or buggy) or because they don't realize what it does or how to use it etc. –  Konrad Morawski Mar 14 at 13:53
1  
@KonradMorawski Or because they can't find it. And you can't really predict when they will find it. We changed the background color of our old pages to match the restyled new pages about a year ago, and all of a sudden were getting feedback, "Hey this is neat, is it a new feature?" - our product owner just rolled with it and let them think it was new, instead of telling them that those features had been there for years. –  Izkata Mar 14 at 16:58
3  
You are doing it wrong if the only time you worry about useless features is when it lets you shirk on coding working patches. If you leave this decision until the feature blocks your code, there is a conflict of interest. You would be putting the cart before the horse. Features are determined at the design phase, before you start coding. If you feel like the original design is obsolete, stop coding, redesign, rewrite the spec, and then code without doubting if "anyone is still using this feature". –  Superbest Mar 14 at 21:56
4  
@Superbest: I am pretty sure if you develop a product over the years, there will always be features which were determined within one of the many design cycles of the product, and the feature seemed to be pretty reasonable then to the analyst or developers at that time, but some years later the whole situation and requirements have evolved. The business processes may have changed in some details, other features are in the product with functional overlapping, and the knowledge why some of the now strange-looking things were once introduced got lost. –  Doc Brown Mar 14 at 22:11
2  
@Superbest Several years ago, a feature was added to one of our primary products as a condition of one of our clients not moving to a competitor. Two months ago, while trying to move that feature to a new backend, we discovered that they have never used it, and brought it up with the product owner. Coding blindly is not the way to go. –  Izkata Mar 15 at 3:16
show 2 more comments

5 Answers 5

up vote 15 down vote accepted

There are three main ways I am aware of to solve this problem.

  1. On website use user tracking e.g. CrazyEgg

  2. In apps or web connected programs use phone home features.

  3. When 1 and 2 are not possible, e.g. non browser client programs, sensitive data, behind firewalls or when you decide not to use 1 or 2 then you need to talk to your users. I'm not talking about focus groups or other passive attempts to discern what your users what, but actively engaging them in the development process and having people with experience of talking to customers, selling to customers, and fixing customers problems help you figure out what your customers really use.

As @Doc Brown has pointed out in his answer: users are looking for solutions to their problems and not features. As engineers we are constantly looking how to break solution requirements down to buildable features but we must not loose sight of the reason we are paid to write code, to help with user's problems.

share|improve this answer
1  
1 and 2 are not practical. 75-95% of what the app does is backend work, not a user facing interface and its a healthcare application. Can you elaborate on how 3 might work from a developer perspective? eg "I spot a feature that seems old and obscure. I file a ticket with our product owner. Then magic happens. I either get a "wont fix" response or a new development ticket to remove the feature" –  Freiheit Mar 14 at 13:42
1  
Fair enough, three would seem to be the way to go then. So the best way I think is to have people whos job it is to talk to customers. If you have customer service people then they tend to be a great source of customer code coverage. Otherwise, if your 'Product Owner' is the one who talks to customers then I would say you need to have a proper meeting with them and the software architects, designers, or developers to be able to gain a better understanding of what your customers are doing. The only reliable method I have found is over-communication. Keep talking about customers all the time. –  Encaitar Mar 14 at 13:55
    
If it's a webapp and on a standalone page, access logs should already exist –  Izkata Mar 14 at 17:06
1  
@Freiheit: Being a backend application does not mean that tracking statistics of what parts of the application are being used is not practical. You could report usage to a webservices or generate application logs that can be parsed to track usage. This data can be invaluable: it can justify investment in features and it can also seal the fate of unused features. –  Eric Mar 15 at 23:15
add comment

Start showing a message "this feature is scheduled to be removed on $date, please get in touch with us if you feel this would inconvenience you" whenever a user makes use of one of these obscure features.

If noone gets in touch for X weeks, pull the plug.

Letting users know in advance (and specifying a deadline) is a good practice in its own right, whether a feature in question is popular or not.

If they do contact you, by asking them for feedback, you come across as considerate - customer service points for you. (If you end up keeping the feature, they're likely to appreciate it even more - "yay, they kept it for me")

And in the process, user needs research has just started by itself; you didn't have to nag any unconcerned users to reveal what they think.

Instead you're getting first-hand accounts flowing in in which they tell you why they need it (if they do). And thus a great starting point to decide whether to keep the feature, redesign it, offer your users some alternatives etc.

That's the best logging / reporting feature you could wish for.

share|improve this answer
8  
+1, but even better: disable a feature, but provide a hidden, undocumented switch how to enable the feature again. Provide the information about that switch to your customer support and make sure they inform you whenever a customer asks for the feature. If noone asks for it for a certain amount of time, you can finally remove the feature from your app. Some messages like "leave us feedback" are just ignored by too many people. –  Doc Brown Mar 14 at 14:04
8  
but even better: disable a feature, but provide a hidden, undocumented switch how to enable the feature again - I'm actually inclined to question that approach. Enjoy telling where the hidden switch is to a guy who calls you because they searched for the missing feature for hours yesterday night : )) Some messages like "leave us feedback" are just ignored by too many people - if they ignore it after being warned that the feature is being dropped, this would indicate they don't really care about the feature that much and thus supporting it isn't worth it –  Konrad Morawski Mar 14 at 14:11
3  
I'm not sure it will work. The PHP language regularly removes obsolete features. For many releases prior to the removal, use of the feature or function is flagged as "deprecated", and site/application developers are warned to remove it. Yet, when the feature is actually removed, it turns out that a huge percentage of sites are still using it (and therefore break). Part of this is site owners not bothering to keep applications up-to-date, which is a problem if the developer does not control the version used. –  Phil Perry Mar 14 at 15:43
1  
@PhilPerry I don't think this analogy is very accurate. For starters, deprecating a feature - and telling people about this - is not the same as asking them ,"is it okay if we remove it?". Had PHP developers ever been asked - not that it's feasible in this case - I bet many would take the opportunity to voice their opinion and/or veto. Refactoring your obsolete code base takes much (much) more effort than dropping a note "no please don't take it away, because so and so". Totally uncomparable level of inertia. Also, PHP devs != "several hundred users" (as the OP stated his app has). –  Konrad Morawski Mar 14 at 15:53
2  
My point is: if you suspect a feature beeing used by nobody, you should make it "opt in", not "opt out". And trying to use it should force the user to give your feedback. If you let the feedback optional, chances are high you will get no feedback even from the users which really need the thing in stake. To prevent people from searching for hours, leave the "feature entry point" still in the product, but when the user tries to use it though its disabled, show a message "XYZ is going to be removed in the next version. If you still need XYZ, please call our customer support". –  Doc Brown Mar 14 at 17:03
show 5 more comments

Besides @Encaitar's very good answer: if your App contains some an "obscure or seemingly strange feature", it often helps to analyse "what purpose might that feature have been good for", and could you improve your application by providing a not-so-obscure, conceptually improved feature which includes the original feature as a special case. That would allow you to remove the "strange feature" as soon as you have completed that new, improved feature. The users might have to learn how they have to reach their purpose with the new functionality (which might work a little bit differently at the UI level), but to my experience, users prefer solutions over features. So if a new feature provides them with the same or better solution for a problem as an old feature, and the new feature does not provide a really worse UI experience, most users are willing to accept that.

For example, instead of having some kind of view or tabular data display which provides information in a specific way which was asked for by just one customer some years ago (and you don't know if the customer does use this view any more, or even which customer asked for that view), provide a feature for user-configurable views. Of course, this makes only sense when there were other customers asking for views specific to their needs (and each one wants a different view).

But beware - don't overgeneralize. Do not develop any complicated user configuration just because "you don't know the requirements". There must be a certain number of users asking for such a form of configuration.

share|improve this answer
1  
It's even not necessarily some implementation issue, but a matter of presenting it to the user. People may not even know a particular feature exists (or what it is for). I think this problem is underrated, at least by IT proficient crowd - be it software developers or just power users - who simply can't wrap their heads around depressing facts such as that 9 in 10 internet users don't know about the ctrl + F shortcut - www.theatlantic.com/technology/archive/2011/08/crazy-90-percent-of-people-dont-k‌​now-how-to-use-ctrl-f/243840/ (this could surely qualify this feature for removal, no? ;)) –  Konrad Morawski Mar 14 at 14:28
add comment

If this is a web app or a mobile app, you should look into Google Analytics. It provides very valuable data on the usage of the app and each screen. It tells you what users use the most and the least.

For mobile apps, it also automatically tracks crashes. Though judging by your question, it doesn't sound like a mobile app. Probably desktop or web.

share|improve this answer
add comment

In my experience a combination of technical and management processes work best here.

A typical suite of functions might have the following usage profile:

  • Used throughout the typical working day
  • Used periodically (daily, weekly, monthly etc)
  • Ad hoc
  • For specialists/power users

Management process

If you have user reps, get these to do the donkey work for you. You don't want to be asking every single user detailed questions, waiting for responses and collating the data. That is the definition of ballache. And besides, it isn't really your job.

Technical process

Where possible, add (or investigate existing) functionality to be able turn features on and off. This may (but not always) involve code changes. However, it could be as simple as tweaking a config file, removing a report template, updating a database row etc. You might also want to consider stubbing out code based on conditional compilation etc. If this sounds like a drag, then consider that should you wish to mothball the function, it is easier to toggle it rather than rip out huge chunks of code.

Once both have been done, you should have a fairly good picture of your function usage profile. So armed with whatever tools you developed in the technical process, turn off the features you believe aren't used.

You could provide a grace period for turning the features off but this should have an end date by which time it will be turned off no matter what. You might be tempted to send out an email/memo asking people to agree to this first but don't do this. Someone always sits on their hands, claims they were too busy or is on holiday etc etc. As the great Grace Hopper said: It is easier to ask forgiveness than permission.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.