Writing good code first is a pretty obvious statement, but I'm not sure if people do this. In fact, I think that we make excuses all the time so that we don't have to.

While catching up on Twitter recently, I checked what @UncleBob (Robert Martin, author of Clean Code) has been saying. Obviously he's a smart guy, as pragamatic as they get, and always has useful insightful things to say. Here's the tweet that caught my attention: 

I'm sure most developers would say that they write good code, always. Think about it? Do you? I know I've definitely compromised my quality standards in the past, deciding that it's better to "fix that later" rather than to get it right first time. The minute you do that, you've broken a window. 

While on this topic of writing good code first, you might wonder where refactoring fits (but I hope that you're not wondering!). Refactoring is inevitable, but what really gets me is when refactoring needs to be put down as a separate task in a project schedule. Looks like UncleBob would agree:

So why does it happen?  To me, seeing refactoring in the schedule is an admission that "you're not going to get it right first time, so we'll add in this extra time to fix it later". Surely if there is a concern that the time allocated to a task doesn't cover a complete, clean implementation, the task needs more time. Refactoring is a good thing, but you have to refactor as you go. Don't commit too much code littered with //TODO comments, do it now. 

Having refactor seen as a different task is the same as breaking down each feature into a list of tasks like design, unit test, code, refactor, test. Software developers should know what they need to do in order to produce quality software. The "task" is not just the coding part - it's everything around it.