Make it good

[radiantmatrix]

Above all other concerns to a quality developer is making the software good. Of course, opinions differ as to what constitutes "good" software -- but, there are a few commonalities, ways to make it good:

• Make it Work
  Software that doesn't work is bad software. Period. Software that works conforms to the design and/or specification, and behaves in predictable ways. This is obvious, but I'd be remiss if I didn't mention its importance. <Update>Of course, while conforming to the design is important, all is for naught if the software doesn't actually run. As FoxtrotUniform and jplindstrom note, sometimes making it work means getting something out the door to the users.</Update>
  
• Make it Clean
  The term "clean" can be interpreted a number of ways -- the important thing is that your interpretation fits the realities of your project. Code should be well-abstracted: keep an appropriate separation between method and data. Make sure that you have the rights to any code you reuse. Move code to modules when appropriate. Handle errors, rather than dying.
  
• Make it Secure
  Insecure software is rarely useful except as a "throwaway". Be aware of and avoid common security mistakes (like passing formats to printf as user-supplied variables). Respect file locks and permissions, even if you can ignore them. Play nice! Handle errors in a sane way.
  
• Make it Friendly
  "Friendly" means different things, depending on context. Whoever will be using and/or administering your final product should find it easy to figure out. Make things intuitive when you can, but remember that not everyone will agree on what "intuitive is". Document well. Keep the interfaces logical and consistent. Don't assume user input will always be valid.
  
• Make it Reusable
  There is very little code that will only ever be used once. Move oft-used code into modules. Code with reusability in mind: use constants and globals sparingly, and try not to "code yourself into a corner". Reusable means modifiable.
  
• Make it Readable
  Chances are, someday someone else might have to maintain your code. Be sure to use appropriate in-code documentation. Use POD. TMTOWTDI, but be consistent. Structure similar tasks in similar ways. Use indentation, and do it in a consistent manner. Let the flow of your code reflect, visually, the flow of the algorithm.

Of course, as will all "rules", there are times to bend -- and even to break -- the above. Know your project, and let that knowledge guide you.

Update:

---

As hardburn helped to point out, these should not be construed as "absolute". Compromises have to be made, and made on a regular basis -- that's part of the development cycle. These aren't really "rules" but goals to reach for while coding. It should also be noted that these aren't in any particular order of preference, they are in the order I wrote them down, and that is all.

Also, as with most admonitions, these can be taken too far (except maybe "make it work"). Excessive thrift becomes miserliness; so excessive attention to security, portability, or any number of the other goals can become a poison in its own right.

As dragonchild points out, the first rule, Make it Work, is by far the most important. Lose that one, and you just wasted your time on the others.

---

Is there anything (else) I missed, or got wrong?