Mental spring's cleaning

Today, I'm not going to introduce anything technical tips or features. I'd like to write a few sentences about (not)using design patterns and good practises.
I'd like to review my habits, developers' habits, but only mine?

Recently, I have read two fantastic blog's entries:
1. Ayende Rahien's Nice process but what about the engineering bits
2. Udi Dahan's On small application
and I have started to have more deeper thoughts (which I'm always trying to avoid - the headache is terrible after that ;-)) about my profession and projects I have participated.

It's never a good time to make negative comments and give an instructive notes, but sometimes its a necessity to say a few bitter words and have moment of reflection.

In various discussions I am constantly hearing and reading who is more agile, how to improve the process, how to make each of iteration/sprint in process more efficient and how to meet tight deadlines... but, are those discussions should be the most important ones for developer? Why there is so many opinions and debates about the process if we don't have influence on time-frame and requirements? In my opinion, discussions are not going in the right direction for majority of us. Each of the process:Agile, Kanban, XP, RUP; is good enough to design and create high-quality software as long as developers don't have to bother about it, just using him properly.
Maybe I don't get it, but I worked with two of them which are drastically different, but still the main quallity difference between them was made by people - their knowledge, commitment, teamwork and attitude bring much more than MS Project diagram or white cards well-organised on the whiteboard.

Instead of it there are some things that seems to be lost and forgotten these days. In my opinion more important and worth to be discussed. Things that makes my profession so inspiring and which can seriously damage my family life. Designs patters and best practises... sounds familiar?
So why I feel that we aren't remember the simple principles of object oriented art?
Why we aren't improving and refactoring our code which is our only real value we can really rely on?
Please ask yourself when did you use some of design patterns last time (please leave the Singleton in peace, because in that case the issue is rather in the second side)?
Please ask yourself when did you consider the single resposibility principle during developing some new functionality?
When did you consider the loose coupling principle when you had adding some dependency lately?
Please ask yourself when did you learn some new features last time?
Which new fancy library have you tried?
When have you tried to do your tasks better/different that usual?

My consience doesn't look too good. Most of answers above sounds 'no' for me. I can say more here - it is a pretty normal that we feel a bit unconfortable with the code we wrote sometime, two or three years ago. But I, in fact, I found some code I am shamed of which is no older than two or three months... I have to use svn's blame because I couldn't believe that I wrote it... very sad but true... I have this terrible headache again now...

The winter is ending and the sun is faintly shaning from behind the clouds makes days better and better. I think there is a perfect moment to change things are they used to be. So I have decided to start from my own yard and make a big spring cleaning in my mental working environment and promise myself a few important things:

1. No more comfortable and quick, but simply bad designed and dubious quality solutions. Even if I am faced with a simple thing, even if its only once, even if its only for now.
2. No more code without any comments, both a documentation style ones and a hint style ones.
3. I will start to use unit tests as a one of my common way to develop things, maybe not as much as I should, but like it used to say ex-coach of our national football's team Leo B. "Step by Step", one by one to make a progress in this area.
4. I will spend some percent of my working hours actually refactoring the code and update the assumed flow and model, because what let us be more professional and mature than when our visions become materialized as predicted and designed?
5. I begin to do the task of considering how to do it rather than when I do it.

I hope that I will look at this list this fall and I will be a proud that in two or three points I made a progress...