Things and Stuff Driven Development

A lot of us heard acronyms TDD, Test Driven Development and BDD, Behaviour Driven Development. Those two are development techniques where application code is introduced with leading expectation. In both cases this leader, so called driver, will be a test.

In ideal world Developers would know exactly how to build a test from “never changing” business expectations and will develop 100% bug free and working code.

Everyone knows how far we are from ideal world and because we are a human beings the main driver of development is different then the desired one.

My few years of development experience thought me that there is a wide variety of technically non related drivers in development. Here they come 🙂

Pattern (Ambitious) Driven Development

Someone who has read a lot of books with good coding practices and software design patterns and the simplest code tries to build using a number of patterns. Explanation will be something along lines: For benefits of future changes and improvements.

Blog Driven Development

Writing a code and looking for possible technical difficulties so they can be presented as post on a blog.

End/Beginning of the Week Driven Development

Either to tired after a whole week of work or pissed of that it’s Monday already to do proper work and code.

Copy Paste Driven Development

“Wait, I’ve seen it in a code somewhere. Let’s just take this entire part and past it in here”. Seen it many times, specially when writing tests. Very often test is not testing what it suppose to after.

Google Driven Development

Very similar to Copy Paste Driven Development. Only difference is that Google provides code results to paste.

Hacking Driven Development

I have to say that I’ve been trapped very often in this one. It’s when there is a technical issue, like integration point and starting as a spike to find a best way to solve the problem it turns into hacking entire solution.

Put any more you can think off.

Cheers, Greg