3 ms·

Most time spent in development is wasted

16 points by techdog 18y ago

csomar 18y ago
-- We know that something like 30% to 40% (some experts say 45%) of the features in a software system are typically never used, while another 20% are rarely used. That means over half the code written for a product seldom, if ever, actually executes. -- I agree, but sometimes we don't use a feature only once or twice but using it is necessary. + if 90% of your users uses only 40% of your software features, why not creating several versions (Permuim, starter...) Another point, the most our software has features, the better repetution it would get
- access_denied 18y ago
  Yes, sometimes one specific feature can make or break a product - even if it is seldom used by a minority of it's users. For example some use cases for Acrobat / PDF rely on scripting ability (JS), but the vast majority of PDFs come without embedded scripts.
  - csomar 18y ago
    Thanks I didn't know that PDF have JS abilities!
lallysingh 18y ago
The problem is when you've already sold to your entire market (or close 'nuff). How do you keep getting revenue? Upgrades. When everyone's happy, and you don't want to rock the boat with improving existing functionality (or if you don't know how), you have to add new features.
Flemlord 18y ago
I believe the axiom is that most users only use 20% of the features of any given piece of software. The counter-axiom is that it's a different 20% for each user. I don't believe there's any actively managed software out there with features not used by a single user.
- stcredzero 18y ago
  "I don't believe there's any actively managed software out there with features not used by a single user." I've seen it first hand. I've worked on a commodities app that had a way of turning deals into general patterns, which could be saved and used to quickly instantiate new deals following the same pattern. It was a sophisticated and highly capable subsystem. What do the users do instead? Copy-Paste-Edit! And that's just one example. That app has literally dozens of non-trivial features that have not been used in over a decade of production use. On more than one occasion, we had discussions like: "We'll have to code up a data migration for that change, oh wait, that table is empty!"
CWuestefeld 18y ago
It seems very common that certain customer requirements -- we call them "checklist features" -- won't ever be used. So when I'm deriving specifications, I always pay special attention to separating out the real needs and expectations from the checklist stuff. If you can do that well, then you can minimize the resources invested in the latter. But for whatever reason, those items are still on their list, and we can't just omit them. The trick is identifying which they are, and finding the minimum specification that allows it to be checked off the list.
- lallysingh 18y ago
  I try to split up the work into milestones, with the most immediate, relevant ones first. The last milestone on my list contains all the stuff I never intend to implement. The boss/customer's happy it's on the list, but I know it'll get knocked off when the reality of the schedule sets in.
ggchappell 18y ago
I don't like this guy's approach. Simply noting that a feature is rarely used is not enough information. For example, code for error handling & recovery is typically rarely used. For some classes of products, most users will never need such code. But if you ship without it, then you're shipping a broken product. Not good. Another example is features used only by high-end users. Something like MS-Word (also the PDF format) has some features that are really only used by high-end publishers (in the traditional sense). Microsoft (Adobe) could have left these features out of the low-end products. But that would mean multiple versions of Word, possibly incompatible formats, etc., which I think we can agree would be a bad strategy. Indeed, the success of Word (& PDFs) is, in part, due to the fact that all users can share the same documents. That said, there are some good points here. Throwing in every feature you can think of is far too common, and results in bloated messes. Indeed, Word seems to have been designed with this philosophy. I am not claiming that the feature bloat of Word is a good thing.

16 points by techdog 18y ago

-- We know that something like 30% to 40% (some experts say 45%) of the features in a software system are typically never used, while another 20% are rarely used. That means over half the code written for a product seldom, if ever, actually executes. -- I agree, but sometimes we don't use a feature only once or twice but using it is necessary. + if 90% of your users uses only 40% of your software features, why not creating several versions (Permuim, starter...) Another point, the most our software has features, the better repetution it would get

access_denied 18y ago
Yes, sometimes one specific feature can make or break a product - even if it is seldom used by a minority of it's users. For example some use cases for Acrobat / PDF rely on scripting ability (JS), but the vast majority of PDFs come without embedded scripts.
- csomar 18y ago
  Thanks I didn't know that PDF have JS abilities!

lallysingh 18y ago

The problem is when you've already sold to your entire market (or close 'nuff). How do you keep getting revenue? Upgrades. When everyone's happy, and you don't want to rock the boat with improving existing functionality (or if you don't know how), you have to add new features.

Flemlord 18y ago

I believe the axiom is that most users only use 20% of the features of any given piece of software. The counter-axiom is that it's a different 20% for each user. I don't believe there's any actively managed software out there with features not used by a single user.

stcredzero 18y ago
"I don't believe there's any actively managed software out there with features not used by a single user." I've seen it first hand. I've worked on a commodities app that had a way of turning deals into general patterns, which could be saved and used to quickly instantiate new deals following the same pattern. It was a sophisticated and highly capable subsystem. What do the users do instead? Copy-Paste-Edit! And that's just one example. That app has literally dozens of non-trivial features that have not been used in over a decade of production use. On more than one occasion, we had discussions like: "We'll have to code up a data migration for that change, oh wait, that table is empty!"

CWuestefeld 18y ago

It seems very common that certain customer requirements -- we call them "checklist features" -- won't ever be used. So when I'm deriving specifications, I always pay special attention to separating out the real needs and expectations from the checklist stuff. If you can do that well, then you can minimize the resources invested in the latter. But for whatever reason, those items are still on their list, and we can't just omit them. The trick is identifying which they are, and finding the minimum specification that allows it to be checked off the list.

lallysingh 18y ago
I try to split up the work into milestones, with the most immediate, relevant ones first. The last milestone on my list contains all the stuff I never intend to implement. The boss/customer's happy it's on the list, but I know it'll get knocked off when the reality of the schedule sets in.

ggchappell 18y ago

I don't like this guy's approach. Simply noting that a feature is rarely used is not enough information. For example, code for error handling & recovery is typically rarely used. For some classes of products, most users will never need such code. But if you ship without it, then you're shipping a broken product. Not good. Another example is features used only by high-end users. Something like MS-Word (also the PDF format) has some features that are really only used by high-end publishers (in the traditional sense). Microsoft (Adobe) could have left these features out of the low-end products. But that would mean multiple versions of Word, possibly incompatible formats, etc., which I think we can agree would be a bad strategy. Indeed, the success of Word (& PDFs) is, in part, due to the fact that all users can share the same documents. That said, there are some good points here. Throwing in every feature you can think of is far too common, and results in bloated messes. Indeed, Word seems to have been designed with this philosophy. I am not claiming that the feature bloat of Word is a good thing.