My mantra, learning from the pain

As those who know me, I'm a huge proponent of flexibility within programming. But flexibility is just one aspect when programming. What about features and code cleanliness?
Well I have my little mantra which helps with all of that.

• Keep it small.
  This might be classes, functions/methods and files.
• A purpose must be meet, but this might mean its split over a group of directories.
  However a class, function/method and a file must have only one purpose.
• Can you replace or remove another section of the program and still run?
  This is important, if you cannot remove sections of "unrelated" in terms of purpose then its too highly coupled.
• I need to do x, and its in y, I'll just copy it!
  No. Just no. Make it a function. Reuse.
  Don't be silly about it. Adding two numbers is not appropriate as a new function.
• But its designed with feature x as being the cornerstone!
  Too tightly coupled. Abstract it out. It should be easy to replace any feature or remove it (relatively).
• Lets test! Wait its not testable :(
  It happens. Its okay. Now can we break it up and test that?
  If not forget about it.
• I don't understand x!
  The purpose of that code is not obvious. Make sure its well documented.
  Comments in both for function/method/class and the lines inside.
  However this can be a sign that it needs to be split up and modified. If not code moved to other locations.
• It doesn't work! Help me!
  Okay so what is it exactly doing?
  What should it be doing?
  How can we get it there?
• Half our codebase is a GUI toolkit!
  Then extract it out, make it more abstract and publish it.
  Possibly even open source it. Maybe you'll get some users who will help maintain it.
• But won't that be costly?
  Yes, precisely. It'll help you have a better base code. And hence a better product.
  Not to mention all those lovely examples and documentation you have to make will give you a great understanding of user code with examples. Much easier to bring in new developers on to the project then.
• Rules are made to be broken
  Yes to be broken. Sometimes its good to go against 'best practice'. But if its just to be lazy yeah no.
• Automate release, yeah no.
  If its automatable automate it. It'll save you a lot of heartache over the long term.
  It may seem silly to automate some things as they may only be done once. But what if that thing has to be done again and its intensive?
  Not to mention its the perfect documentation to what you did. You didn't. Automation did it. And will always do it the same way given the same input.
• Theres a bug in production code!
  Release often, patch ASAP, get it tested and pushed into production.
• Cry :'( another bug!
  No, stop crying and fix it. If nobody is taking charge you should. Just remember testers are human too. Unless they are the users. Then they could very well be trolls and aliens for all you know.
• Do you really have to do it? Or can it be done by the software itself?
  Great example, why create UML diagrams to create the software from when you can create the diagrams from source code?
  After all isn't the software the best documentation? (Especially when other types go out of date fast).
• But most importantly, does it actually make sense?
  If it makes sense do it. Otherwise don't. Stop dreaming and do something innovative. After all why would you program?
  
  If you answer "to earn money duhh", quit. Do an art degree. I don't want to know you. Considering I would never trust you with millions of dollars, which IT projects have a tendency to go into.