Miscellaneous Frustrations

And now, I'm working with some few hundreds of domain classes and transfer objects generated out of various "xml" configs and database schema, they are generated in such a way that they follow the language naming rules as well as readability. Well I will tell you it meets the first objective perfectly but not the latter, it's not readable at all but yeah it makes rest of the code unreadable for sure. How clever of you to make it so complicatedly vague and ho-hum long.

Working with generated code is not as much fun as you might have guessed, Sometimes you don't just feel good to read 50+ characters long ambiguous identifier, with all kinds of bad naming conventions, just to assign it a naive 'false'. Just think about it, there are tens of such fields, and much more if you got unlucky, on each object, they needs to be checked conditionally, validated as well as copied to different persistent object properties. What it results in is what I call.. MUNDANE-F*.*N TEDIOUS CHORE that causes a mental weary which can easily prevent you from keeping your eyes open till you reach first '_' in identifier past first ten chars or something.

But there are side effects to all these which you might be interested to know, you become expert and addicted to copy/pasting (so much so that you'll find 4 characters long word a good candidate to copy/paste), you'll learn coding (or typing, does it matter?) from top-bottom/bottom-top rather than left to right, it's so much fast to copy identifier substrings vertically, like a machine. No, You are wrong, Eclipse is not a good tool to work with such task at hand, might I recommend M$Word.

Also, You'll learn quite a few things including the divine principle of copy/paste reuse, why take the pain of refactoring (and wasting time in writing those brainsick tests) for reuse when you can copy/paste so easily and fast? do you care about anyone else reading your code and fixing patching it numerous times? Of course you don't. In fact, you're so clever you've built empire of redundant code, You've replicated your favorite code everywhere in the application making it impossible to eliminate it at any cost, you know you're happy, you can always find that code to copy in need. So you see, with such ingenious techniques you can become better developer and have a great peace of mind. And did I tell you, You'd spend time in redeploying entire application, on the piece of s**t which only runs on Jr0ck1t, every so often because you know how it is - you forget to put a negation in that if statement or that minor object initialization and that misspelled variable and what not. Redeploying is cool, it keeps your cpu-cores busy, your virus scanner doesn't sit idle and you get chance to look at the interesting log statements everytime with different timestamps, compare it with writing tests which can identify this problems in seconds, how lame...

There's so much to learn just so much..

Well, writing all that makes me feel just better :)

Yet another useful reason of TDDying your dev task

I'm one of the true believer of test driven development. To those who are wondering why TDD after all? No, It's not just buzzword, Let me tell you it works, rather It makes your life less miserable! It helps well in many ways.

I'm inspired to jot some recent experiences I'd with an "in-development-legacy" Java Enterprise application, in highly domain centric team (is not fun I know, BA /and not you/ rule that space!), with little focus on code-maintainability because of regular delivery pressure (every software dev. teams I've worked with is not as creative to find outstanding excuse as different than this one, opps that's complex one ;) ).

To come to the point, I just found that if you are new to a *business domain* you might just find TDD one of the most useful technique to ask questions :). You might say WTF? asking questions should be the easiest job on the Earth, ain't it, heh? nah, not always. If you are like me who don't know what to ask (for example situation where there are too many questions to ask about and you are as blank as dry vermouth), Might I advice you to start with a test, because having test will force you to ask dozens of precise questions to start with, apparently you can't continue further development until you get answers for them. Getting answer means you're clear about what's expected of code, the requirements, which means less assumptions and f**k-ups.

Having said that, I've also found when not to TDD, well many would not agree with me but I wouldn't want to judge my code with % of test coverage all the time, which I've found many fanboys in XP-centric organizations do. I mean, come on! Let's not test the obvious code, that's such a waste of time and energy. Well, what I'm not, always, satisfied is lack of time in tddying a lot of complex code just because of less time. The code complexity(cyclomatic or other) is so much so that all permutations will lead me to exponential test counts making it impossible to write tests manually for them (In which case you would love tools like Agitar, if you can afford a license - that is).

Finally, I'm realizing that I'm continuously benefiting from TDD which makes it my favorite technique for development in all environments, what about you?