IDD - the new age methodology of the DD family

Nowadays you may find quite a lot of *DD methodologies which tackle the software development process from different perspectives.

For example TDD (Test Driven Development) looks into the aspect of testing the code before the code is even written to get full code coverage, DDD (Domain Driven Development) tries to analyse the domain objects and design the system in such a way that most of its functionality is based on the interaction between the domain objects or behaviour that they provide, BDD (Behaviour Driven Development) looks at the aspect of the behaviour of the system - how it does what it does and many more *DD's.

But these are all the words of yesterday, what I am about to share with you is a completely new kind of *DD breed - the IDD or Idiot Driven Development. The techniques although not talked about aloud, has infested the software development world and progressingly evolves amongs the minds of the weak.

In reality all methodologies and approaches are tread-offs, which is why you apply each one in the specific places. The IDD however, evolved from those craftsmen that fail to realise that in the wild goose chase for the buzzwords of IT world. What I mean is that the phylosofy of IDD: one good methodology or approach is good, two is better and if I just stick all that I heard and read on the internet into my system it will be just perfect.

One of the reason for this article is that nobody is perfect and I as well found myself in the position were my newly written code, which is perfect of course, looks very much and antipattern... But that is OK, what is not - is the failure to realize that.

What the *DD methods provide is a way of how you can view your system to provide loosely coupled, easy to test and robust systems BUT what happens that while doing so people create such loosely coupled modules that have no meaning a all in terms of business value but are just ways to promote the programer's mojo. I mean it is great that you have a Factory here, which generates Observes, that trigger Visitor on your Composite but why did not you just write a simple method with a couple of basic programming language constructs to solve the business task? I agree that SOLID principles are awesome and I encourage all to use them BUT there is a line which you need to draw that separates a robust easy to undestand system from a million small class application that no-one can understand. I mean, how many of you spent hours trying understand why your systems fails, just to find out that somewere of the way of your patterns stack a different strategy is injected to one of the classes that absolutelly inappropriate.

I guess this concludes my opinion on IDD. I will be posting some of the interesting IDD stuff in my articles - just look at the code snippets and see for yourself:

1. What were we doing in that abstract base class milles underneath the inheritance?

2. We are double checking everything! well, almost...

... more to come!!!