Currently, I'm the lead developer of a project. But my project ended it's development phase a couple of months ago and right now we're at maintainance phase. With all the vendors out of my project, I'm left with maintaining the whole software alone.
When the project was in development, I was the lead developer, architect and manager. These overlapping responsibilities makes it hard for me to monitor and to be too much involved in the development. Instead I was focusing on some of the critical module
architectures, the management stuffs, such as resource planning, meetings, getting people to daily meetings, discussing priorities with users, etc (yes we are (try) using scrum). I found that scrum actually makes developers and users to understand each other
better and we have very good productivity and flexibilities compared to other teams. We don't work long hours, yet the users are very satisfied with our progress.
However, after the project turns to maintenance phase, I found that there's a lot of things that are 'not as good as I hoped'. bad codes, bad designs are littering the software. I need to fix it, but who would ever give me the time to fix the whole software?
So what do I do? Most of the times users demanded that bugs gets fixed immedietly. I can't rewrite the whole code/module in a limited amount of time, so I hack it. Now, this is the time where I'm not proud of my codes. But doing this means more hacks introduced
everytime and the module will become more and more complex... given time it becomes very unmanageable.
Usually when I feel that the module has too much mess, because of the complexity and because of the bugs it contains, I will raise the case to my users. I will usually demand to have the next development cycle focusing on fixing that module and that I need
them to give me a full week or two. What I usually do, though, I don't fix the module, I trashed it, and recreate it from scratch. Now, that is when I'm proud of my codes.
Of course not all users will immedietly give me the time for doing it. So, sometimes I need to work behind their backs. Working with the new implementation as I have the time. And when I finished with it, I demonstrated it to the users. They usually understand
and accept the new implementations. That's also another win for me and when I think I produced codes that I'm proud of.