You've tried quoting the old "rule of 10,000" to your boss. This states that anything worth doing requires at least 10,000 hours of work to become competent. That just brought a laugh because that app store customer or coworker in accounting is going to spend more time drafting a nasty review or email than trying to understand the features you've collected in your app, even if they're features the users said they want.
Sadly, the ideal can often be to convince your customer they don't actually want the feature they've requested. After all, Twitter continues to offer a feature-poor system that imposes a 140-character limit, laughable in the era of terabyte disk drives. Yet it sails on, serene in the knowledge that all those attempts at providing new features are examples of trying too hard.
If only this solution to the dilemma of unending feature requests was available to us all.
Developer dilemma No. 2: How much documentation is enough?
I was sitting in a meeting with an aggressive project manager who really wanted to stick it to a competing project manager. This manager promised that the code coming out of his team would have "documentation," he said, before pausing like James Bond introducing himself and saying, "Extensive documentation."
The only thing worse than no documentation is a bookshelf filled with binders stuffed with extensive documentation. Some project managers love to measure their progress by the pound, and they see more words as better words. Anyone who's slogged through "Moby Dick" in high school English knows the feeling.
We want to know information about the code, but no one has an acronym for Too Little Information. Everyone on Facebook knows the initials TMI.
There is no easy answer for the programmer. Ideally, the code is clean enough and self-documenting enough to avoid the need for long paragraphs explaining just what the code is doing. Code-based documentation doesn't get left behind like text documentation when someone rewrites the code but doesn't get around to the text.
There is hope that an even smarter collection of debuggers and code-analyzing compilers will be able to do a better job understanding our code. The latest versions of the virtual machines keep copious records of which routines are executed. While most of the emphasis is on performance, this kind of meta data can be more useful than real documentation by identifying when data is changed.
But it will be years before we can drink the Kool-Aid and dream about artificial intelligence understanding our code. For now, we're stuck with the problem of how to create just enough documentationto keep everyone happy without shortchanging the feature set.