bgeek.net

This post has been brewing for some time:

A couple of weeks ago I was very amused to get a tweet from Daniel Cazzulino (the guy behind Moq)

The reason I found the text funny was the idea that Daniel found it strange to have legacy parts of an application within a year of starting the application. I realise (in this instance) the emphasis was more on having to separate the API to allow people to continue using the original MOQ syntax without having to modify everything to be in the more Arrange, Act, Assert syntax. However I don’t believe that it’s unusual for developers to overlook the fact that every line of code they write is somehow creating a legacy of it’s own.

There is one inevitable truth that we all have to learn early (or go down in a death spiral of glory) the rules will change. No matter what the project, the expectations will change as people gather more understanding of the problem they’re trying to solve. We all know this, and yet people are unwilling to write code as if it will change.

I’ve come to embrace throw away code. In the essence of the JFHCI approach I find I’m constantly writing stuff that I KNOW i will be rewriting soon.

Why?

• because it gets me and the people who make the changes to the point where they understand what they really want quicker.
• because I can, I surround my code with a safety net of expectations
• because refactoring simple code is much easier than refactoring complex “well thought out but wrong” code.

Get used to writing code as if it’s not hear to stay, get used to it.

After all it’s the truth.