Just say NO!

I know I said I wouldn't post until after I got settled, but I ran into yet another issue where a program was written to just get out the door or without a real architecture for some reason and now there's issues.
No matter how many times it happens, it never pays to short your architecture to get code out the door or to resolve some perceived issue. There are always options. Did you get that last statement:
THERE ARE ALWAYS OPTIONS!
If you have to get code out the door, I can guarantee you that if you do your architecture up front, your code will still get out the door at the same time as if you would not have done your architecture and you'll be able to maintain and debug it in the future!
Also, if you are dealing with some performance issue, be it database or object related, there are always options to work around it or design patterns to aleviate it.
So, never code yourself into a corner by not architecting your apps. Because when you do code yourself into a corner, you're not alone. You've coded your clients into that corner with you. Now that mental picture should help you remember!!!! :)

Transition

Sorry for the empty space. I'm transitioning to a new project and I'm trying to wrap up and train to get things ready to hand off. I have a ton of things (OOA, design, practices, frameworks and more!) to talk about when I get settled so hang tight, this baby's about to lift off!

Composition is not for functionality

In training a developer new to object orientation, the discussion of encapsulation took a turn into composition. It all started with the developer attempting to make an object completely stand alone. When he was done, the object was so bloated with code that you practically had to use a wheelbarrow to move it around. Rather than drowning the boy in design patterns I tried a different approach. I tried to explain that although his intentions were good, how he went about it was not. In his efforts to encapsulate everything relevent to the object, he had also begun to encapsulate functionality in such a way as to make the object a composition of functionality. When we first learn to develop, our throughts tend to be sequential and subsequently, we lay our code down the same way. What that does is to combine the code into streams of functional activity. The coder sees what they want to put in and what they want to get out and think that the gigantic mound of code in the middle 'encapsulates'. It does not. Say it with me: segregate, segregate, segregate. To keep our code agile we must break out functionality in the same way that we break out the changable v/s non-changable portions of our code. What I did to help the developer was to help him see the individual pieces of functionality and help him begin to move those out into separate classes that will manage that functionality for him (I didn't break it to him that he had just started his journey down 'behaviorial programming'! :)

When you're teaching or training or simply helping another developer, don't show off how many technical or OO or DP terms you know. Rather help them by guiding them to the point where they can discover how best to architect their code. They'll learn more, appreciate and respect you more and you'll have a much better developer.

Scaling SQL 2005

There is an excellent article on MSDN on scaling SQL 2005. It's well worth reading and reading again!

Just in case you didn't get the hidden enthusiasm,
SQL SERVER 2005 ROCKS!