

Most time spent in development is wasted - techdog
http://asserttrue.blogspot.com/2009/04/most-time-spent-in-development-is.html

======
CWuestefeld
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
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.

------
Flemlord
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
"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_!"

------
ggchappell
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.

------
lallysingh
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.

------
csomar
\-- 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
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
Thanks I didn't know that PDF have JS abilities!

