From the overwhelming responses, it appears that consistency in development is not all it’s cracked up to be. Maybe this is worth a post:

http://www.australianit.news.com.au/story/0,24897,23501579-24169,00.html

Cheers - Marcus

For example there’s one class for working with arrays. There’s another class for working with UserForms and so on. Rather than being selective I’ll just drop the whole class into a new project where that functionality is needed.

Then there’s all the project’s I’ve worked on in the last decade or so. But like you Simon, I frequently get that de ja vu, knowing that I’ve solved a particular problem before but forgetting which specific project I may have implemented it. The temptation becomes weighing up whether it would be faster to find the prior implementation or just code it again from scratch. I usually dedicate some time to finding it as I’d prefer to implement something that’s survived the real world.

However there are patterns you see over time. Nearly every project requires database connectivity, so I’ve got a class for that. For most projects, you can get the skeleton up and running fairly quickly.

When starting a new project which has an interface, I’ll go straight to the client’s web site and mimic their corporate colour schemes and imagery in the project. Much faster, easier and more professional than coming up with my own. They’ve already paid graphic artists to create an appealing corporate image – may as well leverage off that.

Other aspects of consistency go beyond a code library such as coding style, naming conventions and so on. Abiding by your standards makes your development faster and more predictable (consistent). You reach a point where you don’t even think about those aspects any more – you just do them. This is a good thing as well as a bad. More than once have I encountered someone else’s code which solved something far more elegantly than I would have done because I’m stuck in a paradigm from trying to be too consistent.

Regards - Marcus