During the last months, I was doing software development the 'traditional' way (writing code as accurate as you can, then hoping that it's good enough - HDD, Hope-driven development). When I thereafter reviewed my understanding of Test-driven development, it turned out that there are some concepts that I just don't buy anymore...
This post started out to be a reply to another blog post about some detail of the red/green/refactor cycle in TDD. It ended up as a fairly extensive description of my own personal practice of doing TDD in C#, featuring quite some VS add-ins and discussing some (real-world) aspects of test-driven development along the way...
Most people - even the overwhelming majority of programmers - would say that the main activity of a software developer is "writing source code". But this is a fatal misconception - about 75% of all time and money (sometimes even more) is spent on some sort of maintenance activity. Far too little effort goes in the future maintainability of a software product during actual development, which in turn leads to software systems that cause substantial technical and financial problems..
From time to time (and when there's room for it, of course), I'm doing a Code Kata to keep my programming fingers flexible and to see myself programming outside the usual business context. Lately, I did the KataPotter , and doing it gave me some valuable insights into my coding process...
I am practicing Test Driven Development (TDD) for some time now, and I hardly can imagine writing software another way nowadays, or could even imagine a reason why I should do so. Time to reflect upon my personal reasons for practicing and being so convinced about this technique...
Lately, there was a blog post by Joel Spolsky called "The Duct Tape Programmer", which is very opinionated and caused quite a lot of responses and discussions in the blogosphere. Basically, this post contrasted the duct tape worldview of developing software to the astronaut architect's, forcing programmers to decide between quick-and-dirty solutions on the one side and analysis paralysis on the other. While all objective arguments against that are already made, here are some additional thoughts.
One of the new language features, that come with C# 4.0, is the new 'dynamic' keyword. I was totally horrified when I first read about it, because it makes it much too easy to introduce (undetectable) errors into a codebase, can foster bad coding style, and certainly will cause serious maintenance problems. A rant...
Lately I played around a bit with Aspect Oriented Programming, especially with PostSharp and the ValidationAspects library that sits on top of it. I wanted to see how I could reduce the amount of infrastructural code like e.g. value-checking, which is highly repetitive and error-prone. I must say, I was impressed of what can be achieved...