Some reasons not to use TDD if the conditions warrant are:

• More code is higher risk for bugs.  Bottom line.
• More expensive.  TDD translates into stories/function points/developer time.  I don’t care what anyone says, I still like TAD a little better to get repeatable regressive costs over time.

Use TDD if you are designing things that will benefit from it.  Don’t if it will not.

Object Design?

TDD is a design pattern, nothing more nothing less. While I have read a few books about TDD . . . I wonder, if true TDD people refuse to do up front object design.  The methodology demands refactoring; and therefore following a Fowler idea that design will emerge, TDD practitioners must let objects emerge via refactoring.  I mean, if they are TRULY doing TDD that’s what they would do.

Timeboxing is Agile’s David

Its an interesting experiment to me; I do refactors and look for patterns.  Then I pull them out if needed.  Unless I come up with an estimate, and the project deadline and my manager says “no way jsut build it quick.”  If you get on one of those projects using TDD (I was on one) a LOT of spaghetti code, with lots of test cases, gets written.  Its about as bug proof as any other design style, that is, in those conditions TDD brings no value.

I think its a failure of a lot of Agile methods . . . ignores the reality of timeboxed projects.  I have never worked on anything but; even being relatively young as my first computer class was on a Tandy PET and my first Basic program on a Vic 20.

A Use Case Where TDD would Fail – SUV Analogy

I am actually using TDD do do some PL/SQL conversion scripts right now.   I have to do it old school; and its taking time.  Sometimes I just write the conditions.  Since the scripts are throw away it we can’t store the unit tests in any sort of DB repository (but that would be great for stored procs etc.).  I ran into a bit of a problem though . . . that writing code in TDD style sometimes causes more problems, depending on what you are trying to accomplish.

Talking with a friend I came up with this real-life analogy of where TDD would fail.

TDD thinks it addresses quality but one thing it introduces is possible defects  due to itself.   You have to make a judgement call based on your input factors of time, money, and risk as to whether its worth it to use this design pattern.  For example, it would absolutely be worth it if designing space shuttle software.  And, you had an unlimited budget.

But here’s an analogy where it would fail:

Suppose you are designing an SUV for extreme conditions.  In one case, it’s a highly wet cool condition and in another, is a hot temperature condition.

The designers decide that testing of everything is very important.  So they design in a hole in the engine that let’s you test sludge buildup in one of the cylinders:  you unscrew something and get a physical look.  Basically, a test has become part of the design.

But now the cylinder head is weakened because of the test.  You have introduced a few failure conditions:  possible weakened gasket that will let in contamination and cause engine failure.

• In the wet condition this may be worth while.  Sludge buildup and moisture may be something causes buildup and there would be value to check the state of the cylinder periodically to make sure you don’t need to run a cleaning process, etc.
• But in the hot condition, the gasket could keep failing and contaminants could be introduced via the testing port.  The strategy is just follow a maintenance schedule (TAD – test after), which you would have done anyway, because everyone has to do maintenance.

It’s just a hypothetical but there are a ton of other things in our life just like this.  Vehicles are easy . . . even now they are building all kinds of testing into the vehicles as part of the design (TDD): emissions, mixture, electric etc.  The payoff is that this is very expensive to pay for, and also in increase costs due to specialized maintenance because your every day Joe or Jane auto mechanic can’t work on their own vehicle.  Do vehicles really last any longer?  I’d argue that they do not.  TDD just extended the period between maintenance’s — i.e. you paid for your time up front instead of over time.

I’m not motivated enough to throw away a methodology if it may be useful, and TDD can teach us some things, but I guess the mantra is:  “TDD: do it only if necessary.“

Of course there were other meetings such as reviews of QA test plans, long term infrastructure meetings and pieces beyond the boundaries of the sprint.

SM = Scrum Master, BA = Business Analyst, the rest should be self explanatory.

Code reviews help to:

• Add to the support base of the code.
• Normalize the development techniques on the codebase.
• Add to team cohesiveness.
• Help developers develop presentation and communication skills.
• Force that last 5% execution of the writing of the code.
• Improve code quality and developer skillsets.

I’ve been and hosted in several different types of reviews:

• Scheduled weekly meeting.
• Present-as-it-emerges.
• Sprint-end code reviews (in Agile).

For these reviews to be successful, I find that these rules of thumb are essential:

• Developers only.
• DEVELOPERS ONLY.
• A place to present; such as a meeting room or a quiet bullpen.
• Projects rule!
• Master of Ceremonies: Let the architect MC, a lead dev MC, or rotate through MC duties.
• Everyone should try to present at some time. Many times there are pairs where a stonger personality will always present.  Hogwash.  This doesn’t help the other developer at all.
• Food is a good thing to have there.
• This meeting can last a long time, hours, depending on which review style you use.

Some may disagree with the developers only rule.   But it is essential; this is not functional review its code review and its all about the developers.  Other points of view will create a conflict of interest, especially management, and the goal of the meeting will fail.