Your conclusions are soooo right. Really. It is exactly the same thing as tidyness in your room.
Where does this tidyness come from? It doesn't come from often cleaning up the shit you made, hopefully before it hits any fans. For most people it comes from having an order of things in your shelves and teaching yourself to not drop everything you hold in your hand just where you don't need it anymore, but put it back in the place where it belongs.
My argument is that - and that is where I can be right or wrong - you write good or bad code because you have the skill to do so. And also that you write good or bad code because you have an order for things and a (somewhat engineeringly/scientifical) process of writing code, that the readability in your code does not come from saying "I make it clean now" but from the sum of all the small steps that produce the least amount of shit as a sideeffect.
The thing is, if you have ugly code that is not easy to understand, the author didn't really understand the problem and the solution either. It was more the magician approach, where you put in many things together and suddenly it works approxamitally how the author has planned (probably there are also no good designed structure documents and unit tests in such a case). And then he just said "okay, now it's finished." If you come and "refactor" it, it is actually that YOU will be the one who solves the real problem the first(!) time, because the ugly code obviously doesn't solve any problem well enough (otherwise, where does the bug reports come from that are so hard to solve).
Okay, that is that. But from your argument, lelele, I wonder, if my secon point was also unclear. I meant that you should of course handle the mess, but WHEN IT IS ABSOLUTELY NESSESARY. If you don't need to, if you can live with the mess in this moment right now and if the problems (bugs etc.) are not that bad (e.g. don't need to be fixed at the moment, because there are bigger things to do), then don't solve the problem NOW. BUT ALSO when the time comes and you have a bug, that really needs to be fixed you should take the time and energy and really clean up the code first. In my small experience (2 years are not enough to be really sure yet) a good process is the following:
1. you discover a problem (through bug reports, dying servers, a screaming boss running your way, you-name-it)
2. you define and evaluate the problem (Is it a problem? Do I(!) need to solve it? Is it worth the time I will spent on it? etc.)
3. you write unit tests to keep the actual thing that the program does without changes and find the place in the code where the bug occurs.
4. now that you can not destroy functionality you plan how to change the system that it is more clean. (cleaning up the smallest amount of code possible)
5. after cleaning up your code your problem either is already solved (happens often in my experience) or gets some fixing now (done by you of course).
With this process you reach many goals at once and make sure to not put in resources that are not nessesarily needed. Also you can see that this process is able to handle ugly code, situations where unit tests where forgotton to write and basically many kinds of mistakes that coders do because they are humans (error prone and lazy).
By the way, the same process also works for new feature requests.
Where does this tidyness come from? It doesn't come from often cleaning up the shit you made, hopefully before it hits any fans. For most people it comes from having an order of things in your shelves and teaching yourself to not drop everything you hold in your hand just where you don't need it anymore, but put it back in the place where it belongs.
My argument is that - and that is where I can be right or wrong - you write good or bad code because you have the skill to do so. And also that you write good or bad code because you have an order for things and a (somewhat engineeringly/scientifical) process of writing code, that the readability in your code does not come from saying "I make it clean now" but from the sum of all the small steps that produce the least amount of shit as a sideeffect.
The thing is, if you have ugly code that is not easy to understand, the author didn't really understand the problem and the solution either. It was more the magician approach, where you put in many things together and suddenly it works approxamitally how the author has planned (probably there are also no good designed structure documents and unit tests in such a case). And then he just said "okay, now it's finished." If you come and "refactor" it, it is actually that YOU will be the one who solves the real problem the first(!) time, because the ugly code obviously doesn't solve any problem well enough (otherwise, where does the bug reports come from that are so hard to solve).
Okay, that is that. But from your argument, lelele, I wonder, if my secon point was also unclear. I meant that you should of course handle the mess, but WHEN IT IS ABSOLUTELY NESSESARY. If you don't need to, if you can live with the mess in this moment right now and if the problems (bugs etc.) are not that bad (e.g. don't need to be fixed at the moment, because there are bigger things to do), then don't solve the problem NOW. BUT ALSO when the time comes and you have a bug, that really needs to be fixed you should take the time and energy and really clean up the code first. In my small experience (2 years are not enough to be really sure yet) a good process is the following:
1. you discover a problem (through bug reports, dying servers, a screaming boss running your way, you-name-it)
2. you define and evaluate the problem (Is it a problem? Do I(!) need to solve it? Is it worth the time I will spent on it? etc.)
3. you write unit tests to keep the actual thing that the program does without changes and find the place in the code where the bug occurs.
4. now that you can not destroy functionality you plan how to change the system that it is more clean. (cleaning up the smallest amount of code possible)
5. after cleaning up your code your problem either is already solved (happens often in my experience) or gets some fixing now (done by you of course).
With this process you reach many goals at once and make sure to not put in resources that are not nessesarily needed. Also you can see that this process is able to handle ugly code, situations where unit tests where forgotton to write and basically many kinds of mistakes that coders do because they are humans (error prone and lazy).
By the way, the same process also works for new feature requests.