Tuesday, June 27, 2006
Test this first...
This is, in a sense, funny. "Test first" is extremely similar to a subset of Design By Contract. When you design your test cases, you're basically coding the expected post-conditions for method calls. Funny thing is, I've been a strong supporter of Design by Contract and, more generally, of the liberal use of assertions inside code. In most cases, however, I've found two kind of assertions to be the most efficient (meaning: you get real value from the effort you put in). One of them is the precondition. I want to trap programming errors in the calling site easily, and that's what preconditions do. Another kind is the generic assertion, used between portions of complex algorithms, to make sure that my understanding of program state was right. Long distant comes the postcondition, for a very simple reason: it's the hardest to write, sometimes so hard that is makes no economic sense to write one.
I'll skip a few words on how Design by Contract zealots tended to say mostly the same things as the Agile zealot do (only worse: never code a class if you don't have an invariant ready, never code a method without pre/post conditions, and so on). Zealots have this common tendency of confusing means with ends, ultimately jeopardizing the concepts they try so heavily to promote. [I'll even skip some linking back from Design by Contract to formal methods, weakest preconditions and the like (it would be fun, anyway, to trace some XP concepts back to formal methods :-))].
Enough talking, let's get some code running. Your mission, should you choose to accept it, is to code your way through this little problem in a test-first way. You'll have a class, say Canvas, that can display bitmaps, and where you can also get and set the color of each pixel. Your program must load a user-specified bitmap into the canvas, then draw a circle with user-specified center, radius, and color. The circle must be drawn over the bitmap, with smoothing. You have to implement the algorithm for that (you may borrow from the literature, using e.g. the Bresenham algorithm, but you're on your own about the smoothing).
Please, test this first. No code before you have some meaningful test in place. Meanwhile, someone else will use a code-first :-) approach. Let's see what happens ;-).
Winning later because of test automation? Maybe. Now your algorithm should also take a user-specified pen thickness as a parameter. Are your tests ready for that? Easily changed? C'mon.
Of course, test-first is useful in some cases, and has a very desirable side-effect: classes tend to be designed with the caller in mind, which is a good design concept. (Wouldn't be good anyway to know about design concepts and not just about programming techniques? :-))).
It's just that, like any other technique, we should use it only when it makes [economic] sense. Now, that would be agile :-).
BetterEstimate™ 1.0b released
The paper on why this stuff is useful is almost complete, although I need a little more time to do a sensitivity analysis on some data. In the beginning, I wanted to explain the simple math behind the tool in the same paper, but it was getting too long (and possibly too boring :-)), so that will wait for another one.
Wednesday, June 21, 2006
Re$earch Tool$
To be honest, there aren't many. Many ideas are interesting on paper, but hardly useful in the real world. However, over the years I've brought together a reasonable set of solid Software Engineering concepts that have proven useful within tough projects.
In many cases, some kind of quantitative notion is involved. It could be the estimation of the residual number of yet-to-find (not to fix!) bugs, or a LOC Vs. Cyclomatic Complexity chart for risk analysis, and so on.
Of course, when you deal with quantitative data, tools are useful and sometimes indispensable. We need tools to extract, manipulate and present data. Sometimes, combining simple utilities does the job; sometimes, you need some custom tool (like my BetterEstimate for probabilistic estimation).
In a recent issue of IEEE Transactions on Software Engineering (March 2006), two interesting tools have been presented. One (called Bunch) deals with automatic modularization. It is conceptually simple, quite flexible, and I would say it has a chance of working in some real world scenarios (I'll be following some experiments with it). One (called CP-Miner) deals with code clones (or "copy & paste" code), and is quite advanced, as it can track post-paste modifications, correlate them, and find potential bugs. I'm already using code-clones analysis with simpler tools, and would appreciate using a more powerful one.
There is, however, a large difference between Bunch and CP-Miner. Bunch is freely available (I don't think it's open source, but I really don't care). You can download the tool, use it, develop plug-in for it. The tool is also alive and kicking (which is somewhat surprising, because most academic tools die in a few months, usually before the editorial time of any article about them). CP-Miner, however, is not available. If you look in the authors' sites, it seems like it has been folded in some larger project and then either discarded or kept as a secret weapon.
Unfortunately, this is more the rule than the exception. The paper on CP-Miner cites CCFinder as a precursor (from other authors). I remember looking for that tool too, only to find out that it was given away only for academic purposes, with a great deal of control.
The same kind of information hiding :-)) is applied all too frequently inside academia. I remember asking for some raw data behind a metric validation, and getting a blank stare. Or downloading some tools, distributed as source code that couldn't even compile, and being told it had been abandoned just after publication.
In many cases, you get the impression that authors would love some funding for their re$earch, but being too shy for asking, they keep their toys for themselves, with the $ecret hope that $ome rich company will $hell out $ome hefty money just to have a look. Now, I understand the need for research funds. What those nice guys inside universities don't seem to understand is that a nice article is not enough to attract real money. Placing artificial barriers between products (whatever the product!) and buyers doesn't look like a genius strategy. But then, that looks too much like business, doesn't it :-).
Anyway, universities are not alone in the dying tool fest. A few days ago, I was looking for a tool (Acacia) to create a dependency graph for Bunch. Theoretically, it was an AT&T Research tool. In practice, it seems like it has disappeared too.
I should propose an amendment to the IEEE editing process, whereby the authors of any paper discussing a tool or a metric must submit a working copy of the tool and/or a copy of the raw data, freely available for readers. Guess what, I don't think it would ever pass :-).
