The afformentioned Software post(Part I)

What Makes Good Software Good (and, by implication, what makes bad software bad) Part I
Yes, this is a geeky post, however I promise there's nothing technical and the concepts herein are relevent to everyone who uses a computer.
First here's the post that inspired this one wherein you can read how the real mission of software is to get its users laid. Who knew?
I also should note that I'm almost sure any originally you'll find here is utterly unintentional. I read a lot about software and all of this has been said by people much much smarter than I. However, I think there's value in 1) exposing other people to them and 2) collecting ideas from diverse sources into a cohensive account of "good software."
I was going to do this as on big post
but I think it will be better (for me) if I trickle them out every day and maybe make them a little more in depth than I originally planed
Principle I: good software does stuff
Software is a tool. People use tools to make their life easier. Ergo software should make people's lives easier. Whether it automates a task, facilatates communication, provides information, or enables creation, software accomplishes goals more quickly and easy than they can be accomplished without it. Therefore, no matter how many buzzword features you stuff into you program, if people can't do anything with it, it's worthless.

Corrallary to Principle I: good software does one thing (and only one thing) really really well.
This idea is grounded in the philosphy of unix programmers.
"one thing" can be interperted fairly boardly as a set of closely interelated tasks. Any attempt to make it do more than one thing will invariably scrafice depth for breadth. Even if you have your central task well defined and beautifully implemented, making it do more will at best, result in a crappy implementation of the additonal features and at worst, actively take away from what the program really ought to do.
When I was thinking about this post a well know law came to mind. I just realized it's by the author of the the above, which says "every program expands until it can read mail." There seems to be this notion in the software world that a program must be the only program anyone uses and therefore do everything. At that point, it really doesn't do ANYTHING well. Adding additional "things" bloats the software, creates more opportunaty for bugs, and complicates the interface.
To give an example, I finally figured out why I don't like livejournal. It tries to be blogging software AND social networking software. Now blogging is clearly the primary function, yet it seems that the social networking features (and the related sense of "community") which feel totally tacked on and underdeveloped get all the emphasis.
The same argument applies to the people who say "facebook should have a blog." I'm sure it would be trival to add blogging capability, but it would be awlful because it would be thrown together and either no one would use it or people would use it, think that's what blogging software ought to be and the expectations of the market place will go down.
Note that the exception to this rule is program which are entirely independent, but can be combined to accomplish some new task or make some task easier. A trivial example is merging a complier and an editor to speed up the edit-test-debug cycle.
All for now
-CI