Monday, July 04, 2005
Dropping features
Software rarely gets smaller: we tend to add more and more features. This is probably intrinsic in the software business model or, as Donald Norman argues in The Invisible Computer, in the PC software business model.
As we add more features, some become obsolete. And as we design new versions of a software product, intended to replace the current version, we often have the chance to remove some feature as well. This rarely happens.
Common arguments against dropping feature are:
"users may like it"
"users may feel lost without it"
"there is no direct replacement for that in the new product" (or, the replacement requires some roundabout)
"I would use it"
If you listen carefully, this is more exactly phrased like: "We don't know the way our software is used. People may or may not use that feature frequently or at all".
Of course, the darkest side of this is that if you don't know what users are not using, you may also have a confused picture on how to improve the product, but let's ignore that.
What I find interesting is that we know the solution to the problem (tracing users behavior) and we routinely don't build a decent tracing systems inside the software. Note that the kind of tracing I'm proposing is not related to bug identification: we need an high-level, compact log of feature usage, ideally per-user (although we don't need to identify the user, it would be useful to know how many users are indeed using a feature).
The reason we tend not to build a tracing system is that it takes precious time out of the mainstream development and maintenance. This is where I'd like to see more support from new tools and libraries, but looking at what we're getting, it seems like most people are substantially more interested in having just another way to display a sexy grid on a form.
Anyway, this sounds like a perfect problem for an AOP (Aspect Oriented Programming) solution. All we need is a "FeatureUsage" aspect that can be applied to any method that acts as the entry point for an high-level feature. Well, the aspect may have a granularity parameter to control the tracing. Again, this sounds very similar to the debug-style tracing, but differs enough in nuances (including being enabled all the time on user's machine) that it would probably deserve a slightly different design.
The blurb above about tools and libraries not getting any wiser reminds me of a remotely related paper, "Traipsing through the QA Tools Desert" by Terry Coatta (Quality Assurance Vol. 3, No. 1 - February 2005). Well, I do hope someone will act on his words. My "FeatureUsage" aspect is much easier to get, and I guess sooner or later I'll spend a few hours thinking about it and writing down a .NET implementation using attributes.
As we add more features, some become obsolete. And as we design new versions of a software product, intended to replace the current version, we often have the chance to remove some feature as well. This rarely happens.
Common arguments against dropping feature are:
"users may like it"
"users may feel lost without it"
"there is no direct replacement for that in the new product" (or, the replacement requires some roundabout)
"I would use it"
If you listen carefully, this is more exactly phrased like: "We don't know the way our software is used. People may or may not use that feature frequently or at all".
Of course, the darkest side of this is that if you don't know what users are not using, you may also have a confused picture on how to improve the product, but let's ignore that.
What I find interesting is that we know the solution to the problem (tracing users behavior) and we routinely don't build a decent tracing systems inside the software. Note that the kind of tracing I'm proposing is not related to bug identification: we need an high-level, compact log of feature usage, ideally per-user (although we don't need to identify the user, it would be useful to know how many users are indeed using a feature).
The reason we tend not to build a tracing system is that it takes precious time out of the mainstream development and maintenance. This is where I'd like to see more support from new tools and libraries, but looking at what we're getting, it seems like most people are substantially more interested in having just another way to display a sexy grid on a form.
Anyway, this sounds like a perfect problem for an AOP (Aspect Oriented Programming) solution. All we need is a "FeatureUsage" aspect that can be applied to any method that acts as the entry point for an high-level feature. Well, the aspect may have a granularity parameter to control the tracing. Again, this sounds very similar to the debug-style tracing, but differs enough in nuances (including being enabled all the time on user's machine) that it would probably deserve a slightly different design.
The blurb above about tools and libraries not getting any wiser reminds me of a remotely related paper, "Traipsing through the QA Tools Desert" by Terry Coatta (Quality Assurance Vol. 3, No. 1 - February 2005). Well, I do hope someone will act on his words. My "FeatureUsage" aspect is much easier to get, and I guess sooner or later I'll spend a few hours thinking about it and writing down a .NET implementation using attributes.
Comments:
<< Home
Scusate l'italiano, ma ho poca confidenza con l'inglese.
Ho apprezzato molto lo spirito di questo appunto. Nella mia esperienza di sviluppatore mi sono reso conto che le idee migliori per cambiare alcuni aspetti del software sono nate usandolo sul campo dal cliente e verificando di persona che alcune cose mancavano oppure potevano essere fatte meglio. Ebbene sì, noi che lo facciamo spesso corriamo il rischio di essere i peggiori utilizzatori e quindi lasciamo che idiosincrasie congenite sopravvivano per decenni.
Post a Comment
Ho apprezzato molto lo spirito di questo appunto. Nella mia esperienza di sviluppatore mi sono reso conto che le idee migliori per cambiare alcuni aspetti del software sono nate usandolo sul campo dal cliente e verificando di persona che alcune cose mancavano oppure potevano essere fatte meglio. Ebbene sì, noi che lo facciamo spesso corriamo il rischio di essere i peggiori utilizzatori e quindi lasciamo che idiosincrasie congenite sopravvivano per decenni.
<< Home
