Unix Phiolosophy: "do one thing, and do it well" Comes to GUI World Now

Unix command line is still widely used. Everyday, it sees new users who appreciate it. You don't see a lot of duplicated effort in command line tools.
There's only one 'cd', 'cp', 'chmod' etc..
Then these commands are designed to work together by using standard input/output, redirections, piping, scripting etc. They all work like one family. The output of one is taken as the input of the other and they can be chained in a single line like awesome players.

find . -name 'filename' | xargs -r ls -tc | head -n1

But, each GUI application tries to redo what others have already done. A word processor tries to do image editing, an image editor tries to do word processing, etc...
This leads to a lot of duplicate effort, and wasted energy. We don't see the culture of one program doing only one thing and doing it well. Even if they do so, their is no specification how they work together and how one can achieve something bigger by putting them together.

It seems the answer is near. It is Plasmate in KDE.

Just read http://www.linkedin.com/today/post/article/20130325152022-1791094-my-mother-s-daughter?ref=email

Thought of those days in which I came to know that my was having cancer. I resigned my Job from Virtusa those days, although I was a happy and appreciated employee, and joined OrangeHRM just to have a better work-life balance.

Same feelings.

Use cases or User stories: What is it that we do in OrangeHRM

A user story is very simple and is written by the customer. It's incomplete, possibly inaccurate, and doesn't handle exceptional cases because not a lot of effort is expended making sure it's correct. During development, it serves as a reminder and a starting point for additional discussions with the customer about the full extent of his needs.

No we don't do the above.

A use case is more complex and is written by the developer in cooperation with the customer. It attempts to be complete, accurate, and handle all possible cases. A lot of effort it expended to make sure it's correct. During development, it's intended to be able to answer any developer questions about customer requirements so that developers may proceed without having to track down the customer. 

Yes the above is what we do

XP stories (and similar things, often called features) break requirements into chunks for planning purposes. Stories are explicitly broken down until they can be estimated as part of XP's release planning process.... A story may not even show up in a use case narrative, such as adding a new asset depreciation method to a pop up list.

 No. The above is not done at the specification level. But, probably done during iteration planning.

Conclusion: User stories and use cases do overlap, and sometimes the same at different precision levels. I think we do use cases in 2 digit precision.