Jeremy Miller put a very intersting post up about the First causes in software development 
While I don’t always like the how of delivering his messages, I think Jeremy is generally spot on. In fact he seems to voice my thoughts much more eloquently than I ever could. Anyway his post or series of posts is dealing with some of the choices he made concerning tools and development philosophy and it also tries to explain that while these tools seem to work today, there won’t be anything stopping him if something better comes along.

Now in that article he links to an article by the pragmatic programmers on the principle of DRY and orthogonality. For me the biggest problem of software development is not the techniques or the patterns but it’s the actual language people use. Till this day I still don’t know what orthogonality means although I understand what that word means in a development context. There are countless examples where people overcomplicate things by using difficult words, this is just one more. Anyway I digress :)

The article series he’s referring to is pretty interesting. If you have some time to kill I suggest you read them. It are 10 articles:
Part I - Don’t live with broken windows

Part II - Orthogonality and the DRY Principle

Part III - Good enough software

Part IV - Abstraction and Detail

Part V - Building adaptable systems

Part VI - Programming close to the domain

Part VII - Programming is gardening, not engineering

Part VIII - Tracer Bullets and Prototypes

Part IX - Programming defensively

Part X - Plain text and xml

The reason that I put these links up is not only because they are a great read but also because one of the things they say in one of the articles is that after you wrote 10 lines of code or so you’re effectively in maintenance mode the green field is gone. And that couldn’t be more true after I had some internal discussion about it I definitely agree with that statement and as such one of the primary goals of your development should not be on getting it out the door as quickly as possible but building it in such a way that you or somebody else can get in there and make changes without throwing away half the code base.

I hope you enjoy them as much as I did