Surfing the expansion wave

Software development is a very demanding professional field of activity. Anyone who caresses the desire to make a living of it should be very aware of this in order to take a well informed decision before plunging into this business. It is sometimes best to decline the red pill and take the blue one.

I vividly remember my 1989 student project leader who, after introducing the exhilarating objectives of the Celesstin research project that was done in cooperation with IBM and Dassault, opened the door and took the time to explain the challenges of software development: there would be no shame to leave the room before the project started, but after, it would be a world of pain for everyone. I wish all computer science teachers could do such an introductory speech: many people would have a better fitted job and would stop making passionate developers mad (on the other hand, what would then happen to the Daily WTF?).

For me, the most demanding aspect of our job is to stay current with what is going on out there. Software development, unlike most of jobs, has a constantly growing body of knowledge. All the difficulty is to stay somewhere close to the border of this constantly expanding universe. This is an exhausting and sometimes frustrating endeavor:

• exhausting because on top of our daily paid-for activities, we have to explore this growing universe, very often using our free time and what is left of our brain power after a long day of work to read, download, test, wander and sometimes wade in terra incognita that others have pioneered for us,
  
  
• frustrating because it expands in all directions and it is therefore virtually impossible to stay close to the border all around this sphere of knowledge: everyday brings its wealth of new technologies, new releases, new frameworks, new tools, new methodologies, new fundamental discoveries... We can only chose an area we feel comfortable with and surf the expansion wave as much as we can.
  

Once you have accepted that every morning you will wake up, the universe will have expanded a little and the border will have moved further so it will be another day of learning and discovery, life will be easier. No more dreams of "being at the top" but, instead, the simple path of the craftsman who learns and improves everyday and everyday realizes that the amount of things to learn and practices to improve has grown a littler bigger than the day before.

Now what is the fuel for doing this, if not passion?

Coverage Generation or Generations of Coverage?

While I was thinking of this post, I came along the "32 & 16 Years Ago" section of the July 2006 issue of Computer and was amazed by what I read in the entry titled "Software Testing". It started like this: "The objective of (...) probe insertion mechanisms (...) is not to find errors; rather it is to quantitatively assess how thoroughly a program has been exercised by a set of test cases" (edited by Computer).

This is dated... July 1976! Code coverage in 1976! Golly! What a blunt reminder that we are, at most, building on the shoulders of giants... Humility is definitively the only path that is safe to walk.

Anyway, my current concern with code coverage was to fix the 100% target that I was talking about in my "Programming for Agility" post and that I borrowed from Uncle Bob himself. This is a nice high level target but can it really be reached? I do not have much doubts for code I am writing with my little busy hands but what with generated code? Especially code that contains many conditional branches like the one Eclipse generates for equals() and hashCode() methods?

@Override

public boolean equals(Object obj) {
if (this == obj)
 return true;

if (obj == null)
 return false;

if (getClass() != obj.getClass())
 return false;

final DefaultTodoListItem other = (DefaultTodoListItem) obj;

if (id != other.id)
 return false;

return true;
}

I came with three possible strategies, including one for which I already apologize:

1. Exclude generated code from test coverage estimation: for having written this one, I have already slapped my hand as a due punishment* ! Generated code does not mean intrinsically safe code: it is live code and is subjected to all sorts of possible errors you can imagine.
   
   
2. Use test code generators: great tools like Agitar Agitator can very conveniently generate test cases for all sorts of extreme values that will most probably explore all the possible execution paths of the aforementioned generated methods. These tests would complement nicely the ones written by the developers.
   
   
3. Reduce the number of needed tests by enforcing class invariants: this can be done by working with immutable objects and check for invalid or exceptional conditions at construction time. This also allows to pre-calculate values like hashCode() and toString() rendering. The tests will then target user written code and will exercise construction of invalid objects instead of testing the calls of all methods possibly sensitive to an invalid state object.

Please do share other possible approaches or practices you think of or daily use in this matter. Even if we are the second generation of code coverage buffs, we might still have something useful to say!

____________________
* An efficient self-punishment technique I learnt from J.B. Rainsberger during SD West 2005.

Parallelize This

Software guru Larry O'Brien has started a thought provocative series of articles on DevX that talks about leveraging multi-core systems with concurrent programming techniques.

This lead me to wonder how we, J2EE developers (or JEE developers, for the most advanced of us), could leverage these multi-core systems, which are bound to become our standard configurations. I might be completely wrong but I have not figured out how this could change our practice! Let me detail.

J2EE applications are designed to be deployed and executed on J2EE servers, which are highly multi-threaded environments: any J2EE server will contain several thread pools waiting to process your HTTP requests, or your EJB invocations, or your JMS message submissions... Such a system is de facto a greedy consumer of multi-core or multi-processor architectures.

In fact it requires a lot of talent to ensure that a J2EE application does not leverage this multi-threaded environment. I have seen once such a product: the developers had to be very consistent in using thread unsafe objects to ensure the system would crash if more than one user would use it. Indeed, even the simplest web-tier only application will benefit from the thread pool dedicated to serving web requests.

Attempts to parallelize some processes by creating specific threads can be made, but with great caution as it is not recommended to create random threads in an application server. In fact, for such parallelizing, internal JMS destinations and consumers can be used: this is already common practice.

Besides, it is interesting to note that more native thread execution capabilities will allow to better leverage JVM features like parallel GC. But this is true for any kind of Java applications (for JVM versions greater than or equal to 1.3.1), not only for J2EE ones.

To sum it up, these new multi-core architecture will improve performances of J2EE applications, but without the need for programmers to do anything about it.

This is good news, anyway.

Ban the Nocturnal Gnome!

This is war time, we will not take it anymore! Read my lips: transparently subversive and constantly deceiving actions will not remain unpunished. We will strike fearlessly and get revenge of this odious and hateful rampage:


Yes, Mr. Knitty Knotty, your days are counted! Soon your nocturnal gnomic activities of wire knotting and knitting will be over. The people of Earth can not stand you anymore: your mischievousness, all devoted to mess up our computer connectivity while we are asleep, is coming to an end.

While the world goes wireless, you, Mr. Knitty Knotty, are entering oblivion. You will not be regretted. So long.

Big Crunch Happens!

So, some say that if there is a big bang, there might even be a big crunch. I am far to be as versed in astronomy as Robert C. Martin (look closely at the picture behind him: it is a picture he took during his most recent worm hole expedition), but I must say that what I am currently observing in the code base of NxBRE might well happen for the universe as well. Or not.

Anyway, while I am working on the RC2 of the brand new v3.0.0, I am aggressively refactoring the code base, which basically translates into:

• not adding any new features,
• removing any useless code,
• and simplifying everything that can be.

And I am amazed to see hundreds of LOCs and even complete classes going away!

This seems to be the fate of any software development project: after the big bang of features, bells, whistles and whatnots, a big crunch is bound to happen when enough significant milestones have been reached. At this stage, code smells can be merrily sniffed and dealt with.

Of course, this is only possible thanks to the wide test suite of NxBRE, which contains unit tests, white box tests and load tests.

Oh, what is the point of fixing it if it ain't broken? Well, let me give you the following reasons:

• easier maintenance: less and clearer code means joy to the world,
• faster execution: at this point of the project optimization is not premature,
• pride in your work: you always do better the second time you write some code.
  

The plan is to have v3.0.0 out before O'Reilly's Windows Developer Power Tools comes out and a new crowd of developers start discovering NxBRE! Hopefully what will remain after the big crunch will still be working ;-)

Helping the Helpline Operator

From time to time, the infamous "we always do that" or "we have always done that way" excuse comes up: nothing new here. When hearing such a sentence over the phone, delivering a correct answer might be challenging though. No body language will help you to get through the wall of resistance to change that has just materialized in front of you (well, at the other side of the line).

What could possibly be a straight to the point reply, one that will not hurt the feelings of the other person (a sheer risk when questioning traditions), but will still make the need for change a clear necessity and trigger the reflection required to change one's mind? I propose the following punch lines:

• I did not know it could even work that way!
  
• You have been lucky so far!
• Call Guinness!
  

What would you like to add?