I finally got to reading through many folks blogs this evening. Here are several interesting posts that I eventually drilled through to:

Is Static Typing a Form of Bad Coupling? - More static/ dynamic language stuff

Finlabs - REAL COOL Algorithmic Trading
The 48 Laws of Power

Development Abstraction - go Joel - this is a great article. As Jeremy put it - I had almost given up on Joel - but this IS a great article - I particularly like this:

Management, in a software company, is primarily responsible for creating abstractions for programmers. We build the yacht, we service the yacht, we are the yacht, but we don’t steer the yacht. Everything we do comes down to providing a non-leaky abstraction for the programmers so that they can create great code and that code can get into the hands of customers who benefit from it.

That is just great. I call this idea “Building Boxes”. We try to - in essence, build boxes for the development teams. We build non-leaky abstractions - and they fill up the boxes. I talk about this all the time - well said Joel!

Go Obie - A web-based IDE for Ruby on Rails

Oh yes - SharpRobo - I am a FIT fan - so this ROCKS -

SharpRobo is a Functional Testing and Recording tool for WinForm applications written in .NET supported language. It supports all the standard WinForm controls. SharpRobo records the tests in FIT format which can be played back using Fit (File or Directory Runner).

More cool stuff via Obie - ActiveMessaging - for Ruby.

Lots of interesting stuff in the world as always

-Chris

There is yet another debate on TDD going on. Basically - folks do or do-not-practice TDD. The mindset of TDD is one that is useful in my thinking. I think too many developers - even quite good ones think; “I do not need to write tests”, or “It is not a good use of my *expert level* writing unit tests”. Here is why I disagree:

1. It is true that better developer write better code.
2. It is also true that better developers can turn out more code -they are more productive.
3. It is also true that developers are people - therefore make errors.
4. It is also true that *better* developers are the only ones on YOUR project.
5. It is also true that software spends 80% of it’s lifecycle in maintenence.

This all means that there will be lots of code - errors to start with and that more and more code will change and be added (usually by people other than the original author). Tests are needed to maintain the integrity. When we make changes to software - we need to know if/ what we break. Tests are needed !
For reference - here is the chain of events that caused this post:

The instigation (Rocky), the chastisement (Jeffrey), the retort (Rocky).

These are interesting reads. In essence, Rocky is not much of a TDD guy. I will say that in general - I have not been much of a Rocky fan - not sure I really generally prefer his ‘way’. That being said - I can certainly understand some of what he has to say. I also respect him and I do not want to belittle that here. ‘Getting’ TDD takes time, effort and it is part of a whole picture. I think we NEED TDD- but I do not believe it stands alone as ‘the way, the truth, and the light’ of development.

Jeffrey on the other hand ‘gets it’ regarding TDD. I will add that on the whole - I tend to see eye to eye with more of Jeffrey’s ‘way’ (at least what he writes about). Jeffrey believes that TDD has added greatly to his bag of development tools, I agree there.

I will reply to 1 point:

Rocky thinks developers dont think test first.…

I think that developers DO think test 1st - they just don’t know it yet. If they do not - they should. What I mean here is that when you are desiging a class - you should generally be thinking about how you WOULD LIKE TO USE THIS CLASS. This is the central idea that TDD helps draw out - when you are writing a class - think about how you expect to use it, write a test that would make that desired usage true, then make the class act as you would like it to ideally.

Practicing TDD helps you to focus on the desired usage of a class/ method. Without TDD- developers will focus on embelishing a class with all the right setters, extra convenience methods etc. These things add code and provide no value until they are required. At such a point in time, these methods should be added. This brings my 2nd point - that TDD helps keep your code LEAN. Since you are focused on just implementing what you need to use at the moment - you are not overcoding.

I will end by saying that TDD is NOT the only thing that can help developers change their mindsets. TDD - when used with Mock frameworks, when used with IoC, when practiced with a team that ‘gets’ all of those things is MUCH stronger than when used alone (although I do believe TDD when used alone is still useful). My point here is that TDD shines much brighter when it is used in an environment with accompanying practices and efforts.

The same can be said about IoC. Inversion of Control is most useful and it really does make your code more flexable. That being said - it ALSO works WITH TDD. It supports TDD- you can pass in mocks or other classes into your code to test it. IoC helps you write testable code. Without IoC - people must ask themselves “How can I test this” and then they can say “this is not testable”. This I believe is how a lot of TDD efforts get squashed. People practice TDD without the supporting practices.

Anyhow - that is enough for me for now.

-Chris