Blog

Don’t you just love when users come up with new feature ideas at a microprocessor clock rate. Even before you finish developing one, five new requests pop up. This is a disease, and it’s called featuritis!

Featuritis doesn’t mean the features are just sporadically requested and developed ad hoc. Oh no, this process can be totally “controlled”, all these requests can as well go through a proper change process, with requests, analysis, approvals, papers circling about. When it comes to changes, some customers behave like they have have unlimited budgets. In the end, these requests pile up on your desk. And most of them smell one-off.

What do one-off feature requests have in common? A few things:

1. They are all requested by a specific somebody who needs to accomplish something, but doesn’t know how to do that the easy way around.
2. It can be accomplished an easy way around.
3. Nobody else needs it, because it is either not necessary at all, or they know how to accomplish it the easy way around.
4. These features don’t see much runtime. They are typically used only once…
5. … provided the user who requested the feature didn’t already figure out how to accomplish it the easy way around, while  waiting for the developer to deliver it.

So, what do you do with these features? What a question! You develop them, of course. What else would you do? They have been officially requested, they have been officially approved, so they better get developed.

Once I worked on a project where new report requests were popping up like popcorn, and all of them were routinely approved by customer’s project manager as “critical”. Once they needed these two columns, then another two columns, then grouped by this field, then by another. I fought and lost too many battles trying to explain how extracting data from NAV to Excel does a much better job, but it didn’t work out–the customer wanted it “all integrated”. So I kept the developers busy.

It was curious that the customer never ever complained about any issue whatsoever with any of these reports after they were developed. With reports, there are usually several cycles of improvements: add this, remove that, rearrange columns, make bold, but with these, nobody ever complained. Not this time, not with this customer.

Even more curious was that during an inspection one day, I decided to personally test some of the reports, so I ran them, and many of them threw an error at me immediately. I opened them only to find that the very first line of C/AL code in the OnInitReport trigger was something along the lines of this:

It was generic enough not to raise any suspicion of the prank, and looked serious enough to solicit a phone call to support. But guess what, nobody ever called to complain about this.

When I inquired about this, a developer told me: “I did it on purpose, just to see whether the users will complain.” The fact that they didn’t, proved that these reports were totally unnecessary in the first place, and the problem that triggered them was solved in the meantime (or forgotten about altogether).

This little prank the developer pulled on the customer was a fantastic cure for featuritis–it showed with mathematical precision how many of these “critical” and “must-be-integrated” features really were needed, and how much money actually was wasted.

Now, I most certainly don’t suggest or advise that you do something like this, there are far better ways. However, when your customer exhibits a slightest symptom of featuritis, if you are on really good terms with them and their project manager doesn’t believe all those requests aren’t really necessary, you might try it just to prove your point.

P.S. Two ways are far better:

1. Don’t actually program any errors: simply “forget” to compile the object. This is much less obvious.
2. Develop a feature usage tracking functionality, and log every usage occurrence. Two months into deployment of any feature, you can send to the customer a nicely looking report showing exactly how many features just sit there waiting for someone to start using them.