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?

Importance of System Metaphor

Kent Beck describes System metaphor in his legendary book Extreme Programming : Embrace Change as A Story that everyone in XP team can tell about how the system works.

So? Why do we need one more buzzword? Why should I care about it?

Consider a team working on a large software application; typically work is componentized by the architects and/or managers. Every member works on specific part of the component or on specific component. Few people (Software Heroes) know what is the real picture of the application and how it works or is supposed to work. (As a metaphor, every member in group is holding/attached to parts of an elephant, some one is holding his pillar leg, some one holding tail and few holding trunk and god-sized ear; while no one knows how he looks like and how to sell it! Nawal, thanks!).

The result? Software heroes become the concentration point (High risk :)); lack of shared vision in team leads to communication gaps (Our product can generate application, end-to-end in three different platforms); Everyone in the team has her own (mis)understanding of the application (we're building a modeling tool, no- it's a part of framework; ok, that framework is persistence framework- may be that framework is generated using our tool); frequent suboptimal technical decisions (e.g. selection of specific framework which may not fit well with other's work- we'll code GEF editor, we will generate GEF Editor using GMF); rework/duplication (existence of several similar utilities in different module);

Having worked in such scenario, I realized that lacking shared vision or system metaphor results in chaos (implementation to deployment), countless bad decisions and loss of interest in regular work. Everyone becomes concerned about his/her own work rather then end-product (customer satisfaction) - there is no more a collective ownership. Work becomes chore and no fun :(. We may even lose out good ideas from team which might be real worth. Team becomes just a mixture of testers, coders, analyst and so on(and you'll not mind being called a Java Resource!).

One more thing I love about XP is, it keeps everyone informed of what is going on, which in turns backs feedback cycles. When everyone knows what is going on, they participate in overall effort rather then mere work assignment.

I understood the importance of system metaphor the harder way..

Experiments with Continuous Integration

Ok, I've build yet another continuous integration tool. May be it's not as cool as CruiseControl or Continuum etc. but it serves the purpose very well.

We've a working set of around 1 million lines of Java code, scattered around 72 plug ins and features. It generally takes around 15 minutes to do a complete build and CVS fetch takes horrible half an hour, Ketan keeps reminding me to migrate from CVS to SVN and I should do that soon. All in all, It takes around forty minutes to export the BluePrint Foundry (BPF).

Manual build is too painful, which forced me to do something smarter. I'd initially setup a automated build with the help of:

• Eclipse PDE RCP Build script running as headless ant application.
• Few utility DOS Batch files (I know, it sucks) for fetching src, moving and rotating build files according to days.
• Windows Scheduler to run the nightly build.

It took two days of research to set it up and get it running successfully, it made life very easy until we started off with major refactoring to make BPF feature- based.

Some where in the dark corners of the "PDE build code" is the assumption to build features in alphabetical order(see bug for details), we've few features which have non-alphabetical dependencies. However it works perfectly in eclipse workbench because all(installed+workspace) the plug-ins are visible in the host platform, but not in headless PDE Build. I'm still struggling to make it work again.

In the mean time...

A quick look in to product export action tempted me to develop a plug-in which can export product in one shot, which can, then, very well can run as head-less eclipse application.

All it took was two hours of code browsing and extending the job and putting appropriate parameters in FeatureModel VO and executing that Job. Hmm.. it still required me to go on build machine and run that, with code in my hand i can configure very good scheduling framework to build. However, that would have been too much of time-investment at that point, rather i wrote one JMX Service which can be triggered from my workstation, cool and pretty easy.

Now, I've a build utility which can be remote triggered from any tool which understands JMX and can work with existing PDE builds. It will continue to make my life easier until the bug is fixed and I've a patch.