Watching "Is tdd dead?"

I have just watched is tdd dead with Kent Beck, Martin Fowler and David Heinemeier (not sure who he is) and here is my very biased take on it.

Kent Beck: To make a design's intermediate results testable, comes with a cost. (The cost is that you are stuck with that, possibly wrong, intermediate result. You end up force programming)

Kent Beck talks about code aesthetics. Talking about product aesthetics is a common property I observed in many great tradesmen.

Kent Beck: I don't want to twist the design just to make things more testable. (Neither do I mates, neither do I. Fills me with rage that)

Kent Beck: I mock (almost) nothing. (I think he is being kind)

Kent Beck: Mocks couple tests to implementation, making re-factoring impossible. (Like a breath of fresh air. There is actually an anti-pattern for that, it is called mock driven programming)

Martin Fowler: Self testing code is important. (Cannot agree more)

Actually, we can assume Kent Beck is the inventor of TDD, and I would advice everyone to read the book that started it all.

Read and learn.

Trigger happy programming

You come across an issue like say, the code is dog slow. What is the course of action? For the stuff I do for fun, I rewrite the whole thing. But being a responsible citizen, I don't do such things at work. Here is what I do; (for a more philosophical discussion of problem solving refer to 'zen and the art of motorcycle maintenance')

I have been programming for a while, I am entitled to have a hunch. So I do a bit of 'shotgun debugging' which consists of randomly fixing pieces of code which look like probable causes, hoping that the problem goes away. Sometimes it does go away, we go to the pub.

There should be a limit tho where you start to experiment in a more controlled way. Measure, change one bit, measure again. Change only one bit at a time. The transition between two modes of action determines a programmer's 'trigger happiness factor'.

There are two considerations, usually highly correlated, to make the call for the mode switch; the amount of programming time required and the depth of code that will be replaced.

I have seen people replace whole sub systems on a hunch, spending months. Some are good programmers and can get away with it, I am usually cautious.

Anyway, there is no conclusion here, all you have to do is to keep it real.

null - the epic Java fail

One of the greatest fails in programming history is the invention (and inclusion in java) of null. What is null? A concept borrowed from c, with a meaning like an uninitialised pointer.

But hey, there are no explicit pointers in Java? Anyways, it kind of means that you have, or will in the future have, an object that may or may not be there. Or a method returns an object but it may not. Below is a concept I borrowed from Scala that better reflects optionality.

public void doStuff() {

      // returnAStringOrNot returns Some<String> or None

      Option<String> aStringOrNot = returnAStringOrNot();

      if (aStringOrNot.none()) {

            doSomeOtherStuff();

      } else {

            String aString = aStringOrNot.get();

            doSomeGoodStuff(aString);

      }

      //or similarly

      for (String aString : returnAStringOrNot()) {

            doSomeGoodStuff(aString);

      }

}

private Option<String> returnAStringOrNot() {

   return inAGoodDay ? Option.Some("Hello") : Option.<String> None();

}

What is your favourite programming practice

People talk about programming methodologies, processes, test driven development, extreme programming etc. Most of them quite religiously. Youth these days are born into this stuff.

But we still see very poor code. Test driven, agile developed rubbish.

Why?

A lot of people miss the essence of a good program:- a good abstraction.

At times of OO there was more focus on getting a good abstraction. Trying to come up with the correct objects used to lead to better abstractions. People talked about crc cards, design reviews...

Then the design stuff got a bit out of hand with uml days. We started to have architects that only design and slave programmers that only program. Then came agile programming to remove useless upfront design. But somewhere along the line, focus on good abstraction is lost.

If programming is like climbing a mountain, a good abstraction is a path around the mountain, gradually increasing the altitude. A bad abstraction is attacking the mountain head on. You can 'force program' to completion, but what you end up with will be very hard to understand and maintain.

If your code is not flowing, if you are inventing additional, after thought mechanisms to keep it under control, may be it is time to take a step back and revisit your abstractions.