Tuesday, October 20, 2009

The duct tape programmer and the patterns geek.

Is there a middle road.

I just finished the book "Design Patterns In Action" and I am starting the "Refactoring to Patterns".

Then I find the following post by Joel Spoolsky:

A danger of our undefined industry is addicting yourself to bits and pieces underway. You get pet peeves that are secondary to the actual business that your profession is a part of.

I am completely sold on TDD, but there certainly is a ladder for its business value with distinct stages.

If you don't have coverage or reliability on your tests, you can't refactor with a vengeance.
If you don't do tests first, you have significantly less chance of producing decoupled code.
If you can't refactor, you will still produce a mess.
If you can't refactor into patterns, you wont see the tests driving the design.

But, at the end of all this and you leverage TDD to its fullest, have you become overacademic along the way?

Does TDD, in all its glory, scale downwards?
Both with respect to project size as well as timeframe.

Are there scenarios where your excellent TDD skills scale so bad that they become an obstacle to getting things done and shipping it?

Robert Martin says "Do not go fast, go well".

My perspective is that IDEs that promote a test first discipline and powerful add-ons like Resharper or Coderush makes this discipline go faster and sturdier. Also, future architectures seem to promote logic and presentation in a more clear cut manner.

As I've stated in an earlier blog post, the jury is out and TDD won, but I appreciate the duct tape programmer perspective. Although I suspect he is a dying breed within the mainstream where people have to maintain code bases and incurred technical debt carry interests.

Thursday, October 8, 2009

When do you accept a Requirement spec.

A prime directive whenever you decide to leap to a new technology/methodology/discipline is to make sure that you have added value to your repertoire. You should GROW, not CHANGE. You should trash what does not work, but you should not trash apples for oranges.

Like Robert Martin says: "You should not only absorb why waterfall is bad, you should also know why it was good (at times)".

I have started to appreciate certain indicators when it comes to whenever a requirement spec is justified.
Notice the phrasing above; I put the onus of waterfall applicability on the person wishing to present me with a requirement spec. The burden of proof is on the person professing waterfall, but it defaults to Agile.

In his book "Clean code", Uncle Bob quotes several nestors within our field as to what their opinion is on clean code. Ward Cunningham comes with one of his characteristically apparently annoyingly redundant comments:"When the code is pretty much what you expect".
At first glance this is seems like a cop-out of answering the real question, but upon closer reflection, there are subtle brilliances within this very simple answer. Reading clean code should not make you pause, there should be little "flavours", nothing should feel forced, there should be no need to mentally context switch within a single class, the name of the class and class members should give you a reasonably good opinion as to what lies behind it.

For all my thoughts on the little nuggets of factors that combine into a good requirement specification, it basically boil down to the same:
When writing and reading it is all but a formality, then it is a justified specification.

The fabled animal "irreducably complex infrastructure" may still really exist, but you should still have a go at it with real tools before calling in the medium.