Write programs that do one thing and do it well

I can grasp the part "do one thing" via encapsulation, Dependency Injection, Principle of Least Knowledge, and You Ain't Gonna Need It; but how do I understand the second part "do it well?"

An example given was the notion of completeness, given in the same YAGNI article:

for example, among features which allow adding items, deleti开发者_开发知识库ng items, or modifying items, completeness could be used to also recommend "renaming items".

However, I found reasoning like that could easily be abused into feature creep, thus violating the "do one thing" part.

So, what is a litmus test for seeing rather a feature belongs to the "do it well" category (hence, include it into the function/class/program) or to the other "do one thing" category (hence, exclude it)?

The first part, "do one thing," is best understood via UNIX's ls command as a counterexample for its inclusion of excessive number of flags for formatting its output, which should have been completely delegated to another external program. But I don't have a good example to see the second part "do it well."

What is a good example where removing any further feature would make it not "do it well?"

I see "Do It Well" as being as much about quality of implementation of a function than about the completeness of a set functions (in your example having rename, as well as create and delete).

Do It Well manifests in many ways, some ways of thinking:

Behaviour in response to "special" inputs. Example, calculating the mean of some integers:

int mean(int[] values) { ... }

what does this do if the array has zero elements? If the items total more than MAX_INT?

Performance Characteristics. Has sufficient attention been given to behaviour as the data volumes increase?

Dependency Failures. If our implementation depends upon other modules or infrastructure what happens when these fail. Example: File System Full, Database Down?

Concerning feature creep itself, I think you're correct to indentify a tension here. One thing you might consider: you don't need to implment every feature providing that it's pretty obvious that a feature can be added easily without a complete rewrite.

The whole purpose of this advice is to make you favor quality over quantity.

The concept of one thing is subjective and depends on granularity. Would you say that a spreadsheet application does more than one thing if it can also print, or is that part of that one thing?

The point is that you should make sure that any feature, and the application itself, is done and will delight customers before you scramble to add new features.

I think your question points out the fundamentally organic nature of feature creep, and in understanding that nature, you will be empowered to meditate on the larger question.

Think of it like a garden: If you plant one thing and plant it well, say, a chrysanthemum, you aren't done at simply planting the seed. In fact you'll need to ensure that the soil is well tended, that the area is sufficiently protected, that the season is right, etc.

As your chrysanthemum (your one thing) grows, so too will other competitive plants - some that need to be weeded out and others that may actually compliment the original one thing. In fact, these other organisms may in some cases prove vital for the survival of your one thing.

Like those features that YAGN, a bit of vigilance is required to determine which weeds represent feature creep and which represent vital and complimentary functions.

Regardless, having done it well means simply that your chrysanthemum is hearty, healthy, and on-time. :-)

I would say an email program without the ability to add attachments would be a good example.

This may sound like an odd example, but I'd say dropbox is a good, albeit complex example.

Its managed to beat off a swathe of similar competing apps, through a dedication to simplification and a lack of feature creep tha,t as you mentioned, would violate the 'do one thing' principle. The ap lets you store documents in a folder that you can access anywhere, and that's about the limit of it. They drilled down to the core problem, and solved it in a way that works perfectly well in 90+% of cases.

Its hard to put a hard and fast rule to it, but I'd say that catering to around the 90% majority of use cases and ignoring 'fringe requirements' is the best way to stick to this rule.

I'd guess 90+% of ls use is with no arguments or maybe two or three of the most popular. The 'do it well' principle should focus on what the majority of users need, instead of catering for power users or fringe cases, as ls does with its plethora of options.

This is what dropbox does successfully and why it is pretty well agreed upon as an example of good application design.