Dare to Question TDD?

I decided to write a quick follow up to my post yesterday. I made the following comment on this blog post:

TDD is a flawed paradigm by the very nature of having to write more lines of test code than production code. It has undoubted good side affects like higher quality code but nobody ever wants to discuss the flawed nature. Anybody who dares challenge it is slated as unprofessional:

Typically we get the same old cries of either being unprofessional or as is in this case is of Thomas Eyde we get the predictable cry of “You aren’t doing TDD” obviously. He posted the following quote:

You aren't doing TDD, obviously, because you don't want to use flawed methods. So how do you create your quality code? How do you verify your code does exactly what you intended it to do? How do you avoid to write code you don't need? How do you avoid to break working code when you apply your changes?

It is tedious for me to try and prove whether or not I do TDD, I can point to the horn tests as examples of the tests I have written. Anyway to get into such a debate is boring. For the record, I never once said you should not do it.

My question to the few people out there who may read this blog is a very simple one...

Why the hell can we not question TDD’s worth? Every time someone dares to question the flaws, they get slated as unprofessional.

The very fact that we end up writing more test code than production code makes me feel uneasy about the whole concept. TDD takes a very long time to get up to speed if you have no mentoring to accelerate the learning. The whole concept just seems loose with no clearly defined boundaries to help reign you into to a tighter feedback loop. For me, it took a while for the penny to drop with respect to how important it is to write a clearly defined failing test. I must stress clearly defined and not just a failing test.

TDD is flawed and instead of getting hot under the collar every time somebody dares to question it, we should be thinking of ways to improve the very loose and unguaranteed way the paradigm works. Of course I could just be very slow.

Or are we saying that we are totally happy with the experience and we will just leave it at that..................?

Holier Than Thou

I have to say I have enjoyed the duct tape furore thus far. The rumpus has succeeded in bringing a number of annoyances to the surface for me that have been bubbling like a geyser for some time.

Scott Reynolds reaction is the norm for the reaction of what I will now deem the guilty and both this post and this post are better articulated answers to the haughty and ill versed reaction of Mr.Reynolds.

What this whole duct tape debate has said to me is that as developers we are more concerned with the internal structure of our code than the external behaviour of the products or services we produce.

When do you ever see a developer blog about usability issues of a UI app which let us face it is what a lot of us are working on?

Usability is one of the main reasons for the failure of a UI application. We really need to grasp this concept while more and more development is outsourced.

I have had the misfortune to work on a project with a very well versed project lead whom in his wisdom had a dozen user stories and even a bounded context before we had a single web page when we were working on.......wait for it..............a web application. I fear this sad tale is not unique. You know who are and you should not be let loose on making the coffee never mind producing a working application within a decent timescale.

The echo chamber is quick to insult a code base they have never seen like stackoverflow but they cannot congratulate what is a well performing high traffic website. They have no interest in the external behviour but have perceived a big ball of mud for a codebase they have not laid a single eyeball on.

People seem very quick to blogboast about how they have adopted kanban, scrum, git or whatever the hell is du jour but all this is inward facing and does nothing for the saleability of the product.

TDD is a flawed paradigm by the very nature of having to write more lines of test code than production code. It has undoubted good side affects like higher quality code but nobody ever wants to discuss the flawed nature. Anybody who dares challenge TDD or some of the other craftsman attributed methodologies is slated as unprofessional. As an aside the term craftsman connected to software development makes me want to vomit. I use TDD to drive out the design of my code but have more or less abandoned integration tests as brittle and a waste of time. I use TDD because at this minute in time it is the best way for me to focus my mind in delivering small units of functionality. It works for me but I do not begrudge any developer/architect who does not use it.

The embarrassing thing to me is that this arrogance is something I have willingly subjected myself to on twitter. The other really embarrassing thing is that I am probably just as guilty of these heinous war crimes. After following various better known bloggers on twitter, I found myself getting more and more irritated by the various tweets and retweets that were constantly breaking my train of thought, some of the most annoying of recent times are:

“back to developing stories again, ohhhh yeah”

“Test code is just important as the production code, and it needs to be refactored just as often.”

“Just refactored my Trial Balance code from 640 lines of code to 448. When I was ready to test, everything worked the first time around! Yay!”

“if you could punch a singleton, well, I would simply concede that you are the most amazing programmer ever.”

My answer to the above is GFY and stop taking yourself so seriously, you are just as flawed as the rest of us or you would not be on this stupid medium.

Worse than actually tweeting the above is retweeting the above. The sycophantic nature of twitter is possibly more annoying than the holier than thou aspect. It saddens me to see grown developers :-) of the community local to me go weak at the knees when in the twitter presence of somebody American with a blog. Get a life please.

Before I leave twitter, I want to mention a third and equally as sad breed of tweet that we get, the nonsensical tweet. Examples of which are:

“Wasabi peanuts FTW!”

“Got a cold today, feeling tired”.

My answer is the same as before GFY.

In reality twitter is just another reification of an echo chamber that is defined by the fact that you are following people of a similar mind set. If I sound bitter it is only because I am still struggling to combine the words twitter and bitter into a legible word that I will use for the title of this post.

Just to prove how hypocritical I am, I am going to promote this blog post on twitter.

Another hackle I have back at the arrogance of certain developers is this thread about fluent interfaces we found on the ALT.NET mailing list. I personally hate fluent interfaces that are littered with lamdas but that is another blog post. What annoyed me about this was the arrogant almost prose like post from matt Hinze:

“Would like to chime in here - fluent interfaces that are easy to read
are nice but that shouldn't be the goal. The goal should be making
code easy to write.

Fluency is an output; we achieve fluency writing the code not reading
it. One who can only read a foreign language does not claim to be
fluent in it.”

One would like to tell you where to stick this. I doubt you seriously believe this so I really have no idea what benefit there is from posting such a shambolic comment that you tried to refute you later.

Other random irritations are Roy Osherove’s discomforting Leadership series of blog posts. This arrogant know-it-all seems to think managing a group of computer geeks is about asserting yourself sergeant major style. I’ve personally led a life were previously I have had contact with the darker walks of life and certainly not the salubrious surroundings that I have transgressed to in my reincarnation as software developer. Brother would I like to put you in some of those positions and find out how you lead your way out of that. I found the following quote about team leadership totally stomach wrenching:

“If a developer comes to you asking about what a specific API of the application infrastructure might look like - don't follow your initial feeling. Don't give them your idea of what a good API for that part of the app might look like. Instead, ask them to come up with 3 different possible designs”

3 possible designs, for real? Sort it out mate, you have disappeared up your own ego a long time ago. Such advice is really better suited for the toilet. How about producing some working software you prat?

Yet again we find these great(?) developers more concerned with petty organisational paradigms that are inward facing and really do nothing for the external behaviour or the saleability of the products we work on.