Wednesday, February 4, 2009

Godspeed, Mr. Moffatt

Last night the component developer community lost a good friend. Tim Moffatt, the president of Data Dynamics, passed after losing his battle with cancer.

I remember plenty of times after work spending time with the boys of Data Dynamics, drinking and playing cards. Tim would always hang around to give us hell and hang out. Tim was also good at providing advice (in his own little way!) on business and other matters. I'll raise my glass to you, and hope that you are in a better place.

Cheers.

Tuesday, January 27, 2009

The state of the economy, and how TDD can help

So I'm starting this blog back up as I never got the chance to get any topics of use in while at Sophos. I was recently laid off from the Dublin office and now I am looking for future employment in the Columbus area. I hope in the future I can get a chance to provide some insights into using .NET and open source technologies to help achieve business goals.

In my travels around businesses both big and small in the Columbus area a thought occurs to me - businesses all seem to be out for the immediate results (which is good) without much though to the overall cost in the long term (which is bad). The bigger places tend to use consultants as interchangeable cogs in their huge engines - this is very bad as all consultants are not created alike. The focus should be on the project and the process, and finding people that are good fits for those two things at all levels.

Simply having a mandate from the top to use Agile methodologies, or *DD in your organization will fail if it doesn't have support for the process on a daily basis. As a recent "convert" the the TDD cause I was originally skeptical about it's real value in the world of waterfall-based projects and typical staged development life cycles. It wasn't until I took a look at what most places end up doing that passes for testing that I realized TDD can provide real benefit and cut down on the "QA Stage" of the SDLC being used. Typically followed most places go through a process of design, development, test, release. The development stage works from the designs generated, and then the test department ends up testing overall functionality and behaviors. Because this is constant and repetitive interaction it is prone to errors and can lead to major bugs being released because they simply were not noticed. By using TDD and having a sound design that covers your parameters of in/output you can using tests be more stringent with the code for every release. Computers won't get lazy, and computers won't miss things, unlike people who can get bored testing the same functions over and over, and worse may end up simply lying that it works to get out of testing it in the first place. In short TDD, if done right will provide quality and a dynamic but stable code base to work on that's fun and exciting!