Do corporations hold the secrets to the beginning and end of the Universe?

I chuckled as I read a report in the business rags that SBC and AT&T are in talks about a possible merger. I couldn't help notice that we may be on the verge of a singularity here! Please bear with me as I describe how.

In the beginning there was AT&T and practically every phone call you made from within the U.S. went through her wires and switches. A Sherman Antitrust lawsuit brought forth in 1974 by the Department of Justice was finally settled in 1982, forcing AT&T (a.k.a. Ma Bell) to completely break up her 'monopoly' and divest of her local telephone service providers. The local providers were reorganized into seven independent, regional, Bell-operating companies, commonly known as Baby Bells. SBC is one of those Baby Bells.

Now, according to the Oscillatory Universe model, the Universe started with a Big Bang and is currently expanding. It postulates that eventually, the expansion will slow down, then stop, and then the Universe will begin to contract. The contraction will continue until all of the mass of the Universe is contained in a singularity. This process is known as the Big Crunch. The singularity then undergoes a Big Bang, and the process begins afresh. Sound familiar?

Of course, the Oscillatory Universe model isn't widely accepted by the scientific community. Maybe if the SBC-AT&T merger goes through, there's a good chance the business community will embrace this model.

Email this | Bookmark this

A team of crack developers does not a successful project make

Developers hate schedules. That conclusion is pretty easy to derive. I was thinking of 3D Realms's long-awaited Duke Nukem Forever, that Wired magazine has so appropriately honored with a Lifetime Achievement Award in the Vaporware/Phantom Software category. Now I don't know anything about said company and said product's development team, but saying "I doubt they have much of a schedule" is just stating the obvious. Sadly this isn't the only instance of its kind in the software industry. I believe a vast majority of projects have either no schedule (and hence no deadline) or have no adherence to schedule. No wonder these projects move slower than molasses dripping out of a fur-lined syrup pitcher.

But why do developers hate schedules? Too often they are expected to follow schedules imposed from the top. That is a recipe for failure right there. Then there are those programmers that are involved in scheduling, who often tend to estimate on the lower side. There are many reasons for this:

• The "Oh, I do not want to come across as a slouch" mindset


• Developers feeling they can use this opportunity to prove their hard work and dedication


• Ignoring the fact that the estimate must include more than just the time it takes to write the code


• Not recognizing that testing and debugging take more time than does coding


• Ignoring the difference between calendar day and work day


• Relying on gut feeling more than actual estimation techniques. This is the infamous throwing-numbers-out-of-your-ass technique


• Pressure from management to give 110%, whatever that means!

I believe that the failure to implement a sound, well-planned schedule is the reason many projects have open ended release dates. A lot of us are under the illusion that a schedule is a sacrosanct document that does not evolve. Nothing could be farther from the truth. In real life, the schedule must evolve and accept change just as any other part of the development lifecycle does.

A good schedule incorporates numbers provided by the developers who will actually write the code. It accounts for time overruns by creating buffers for existing features and for things that will inevitably crop up during the execution of the project. I mean, have you ever worked on a project where the requirements haven't changed or where new features weren't added when the design was already solidified? So when preparing the schedule, why pretend like that's not going to happen this time? A line item for that will save you tons of heartache later.

Estimate time required for testing and integration separately from the time to "develop" features. And don't forget that old faithfuls -- documentation and debugging -- either. The schedule must also account for holidays and vacation time for each team member. And while you're at it, add a few days to account for fire drills, sick days and snow-outs | storms | blizzards | hurricanes | Seinfeld marathons on TV.

Good schedules list features and their owners. This very critical. This also assumes that you have completed an iteration or two of identifying what those features will be. You must have a system where people own features. One cannot overstate the importance of the sense of responsibility this inculcates. It also eases bug/RFE assignments and ensures the minimal turnaround time for bug-fixes (because the person who develops the feature fixes its bugs fastest). Also be considerate and don't expect your developers to do more than one thing at a time. A person assigned too many parallel tasks may not be as productive as someone who focusses on one task at a time. You will have one or two people on the team that are fully capable of handling multiple tasks. Good, make sure they get a raise and feel appreciated. But believe me, not every developer has the bilateral proficiency of Leonardo da Vinci.

If you are in charge of creating the schedule and if you choose to embellish the estimates, please bump them up, not down. And if you think you need to cut, then cut features, not the time it takes to develop features.

I do not mean for this to be a flame bait but the Duke Nukem tardiness syndrome is very common in open source projects. My take on it is that most of the projects are run by developers (good ones I might add) and have little or no management oversight. Hence, deadlines are alien concepts and surely crack coders can't be bothered by them.

It is foolish to develop projects with arbitrary time-based deadlines (for instance, deciding you will deliver by March 2006 before you have even understood the requirements and the scope) but it is simply unforgivable to embark without a plan or a schedule. Write a schedule that works best for you. And stick to it.

Email this | Bookmark this

Questionable String.valueOf implementation

My obsession with Strings continues. I just came across an inexplicable anomaly in the java.lang.String class.

   int[] numbers = null;

   System.out.println(String.valueOf(numbers)); 



   char[] characters = null;

   System.out.println(String.valueOf(characters));

These two String.valueOf() method calls display different behavior. The former displays a "null" string. The latter, being rather quixotic, throws a NullPointerException. If there's a good reason for this divergence (I have a hunch there is), it isn't immediately apparent. Can someone please shed some light?

Email this | Bookmark this

When the + operator for concatenating Strings is a better option

Simple but not widely understood fact: the + operator for String concatenation is your best option, an order of magnitude better than StringBuffer.append(...), when the your String value resolves at compile time.

Take this situation

   String str = "This " + " is " + " a " + " test " + " String.";

which represents a rather simplistic example of a composite string constructed from a bunch of (predictable) strings. This will be resolved by the compiler to

   String str = "This is a test String.";

even though you used the + operator to delineate the individual strings.

Update [Jan 24, 2005]: Take a look at the bytecode for a class that declares and initializes two strings str1 (4 through 6) and str2 (7 through 39), one with each approach:

public class TestStringConcat extends java.lang.Object{

public TestStringConcat();

  Code:

   0:   aload_0

   1:   invokespecial   #1; //Method java/lang/Object."":()V

   4:   ldc     #2; //String This  is  a  test  String.

   6:   astore_1

   7:   new     #3; //class StringBuffer

   10:  dup

   11:  ldc     #4; //String This

   13:  invokespecial   #5; //Method java/lang/StringBuffer."":(Ljava/lang/String;)V

   16:  ldc     #6; //String  is

   18:  invokevirtual   #7; //Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;

   21:  ldc     #8; //String  a

   23:  invokevirtual   #7; //Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;

   26:  ldc     #9; //String  test

   28:  invokevirtual   #7; //Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;

   31:  ldc     #10; //String  String

   33:  invokevirtual   #7; //Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;

   36:  invokevirtual   #11; //Method java/lang/StringBuffer.toString:()Ljava/lang/String;

   39:  astore_2

   40:  return



}

Go ahead, write a small for-loop and test this and then compare it with the StringBuffer.append(String) method. Of course, the StringBuffer does far better in runtime String resolution situations. But you already knew that.

Email this | Bookmark this

Are you afraid your coding legacy would be tarnished?

I was talking with some colleagues and one of them complained about how some code he had written a while back -- and was rather proud of -- was being updated and converted to spaghetti by developers currently maintaining it. Now I've had the very same thought before and so I can empathize with him.

We toil to create beautiful code using all our means and faculties and proudly (some of us do!) add our name as authors. Everything we write is consigned to posterity. It is our legacy. As if to proclaim, "I solved this problem!". But sometimes it isn't easy to detach oneself from one's creations. Just like parents never tire from worrying about their children's new-found errant ways, it breaks our hearts to see our code handled by chimps.

Oh, we are so full or ourselves.

Email this | Bookmark this

Leave the gun; take the cannoli: The JDO tragedy

Some people just don't let the facts get in the way of a good opinion. The recent throttling of the JSR-243 on Java Data Objects (JDO) 2.0, is one such example. Companies like IONA, HP, Fujitsu, Intel and Nortel (all of whom have with such hard work made Java/J2EE the way you and I see it today) along with relational database vendors like Oracle, IBM (that otherwise like JDO and love their O-O database vendor competitors) and of course JBoss (who "developed" Hibernate, the other persistence technology) among others have made it amply clear that the JDO spec dies a premature, undeserved death. Technically, after the Public Review Ballot was not approved, the Spec Lead and Expert Group do have 30 days to create a draft for reconsideration. Small consolation though.

I must make my affiliations clear: I am a member of the Java Community Process (JCP) but do not and have not served on the expert groups of JSR-243 or JSR-220 on EJB 3.0.

My problem is not with these companies exercising an opinion, rather it is with the reasons some of them have provided us in their voting comments. Certainly, as elected members of the Executive Committee, they have the privilege of voting on such matters. By that token, they are the Java community's representatives on the EC.

Some have voiced the concern that multiple persistence technologies would end up "confusing" the development communities. Kids, that's you and me. With our fancy degrees and years of design and development experience, We would be led astray by a new persistence option. I think the JDO spec should have lived to face a Darwinian end. It should be you and I, the Java development community that decides if we think JDO is a viable option in our frameworks, products and projects. By preempting that decision, these folks have done us a great disservice. As the Apache Foundation has suggested in its comments, "...we believe that this is something for the market to decide, rather than one company." I agree commercial interests are important and most companies are guided by those more than anything else. That is not bad in itself. I just cannot help but think that the JDO spec was shot by the wayside with the pretension that it was for the common good.

I encourage anybody who has read this far to also look at the results of the JSR-243 Public Review Ballot. There certainly are some gems in there, as far as comments go. You can make up your own mind and may even reach a different conclusion than I have. That's fair. At least you made that decision.

I also encourage you to consider joining the JCP, or if you already are a member, please think hard and weigh all options when you vote.

Email this | Bookmark this

Huygens lands on Titan!

The ESA probe Huygens, until now piggybacking on NASA's spacecraft Cassini, has landed on Saturn's moon Titan. Radio telescopes have tracked a carrier signal which "indicates that the back cover of Huygens must have been ejected, the main parachute must have been deployed and that the probe has begun to transmit, in other words, the probe is alive". Here's the possible timeline [via the Cassini-Huygens mission website]:

1:51 a.m. PST
Huygens Transmitters On

2:16 a.m. PST
Pilot Parachute Deploys

2:17 a.m. PST
Huygens Begins Transmitting to Cassini

2:32 a.m. PST
Drogue Parachute Deploys

4:34 a.m. PST
Surface Touchdown

6:44 a.m. PST
Cassini Stops Collecting Data

7:24 a.m. PST (About ten minutes ago)
First Chance for Data Arrival on Earth

I'm waiting to see what Huygens says when it calls home. In my opinion this is as big as our first landing on the moon. Never before has a prospect of life outside of Earth been so close to being deciphered. If we don't find life, at least we will get a glimpse of what the Earth herself looked like towards the beginning of evolution.

Update [Jan 20, 2005]: It is amazing how amateur enthusiasts have processed raw images and distributed them on the internet faster than space agencies have moved on this task. Here is a collection of processed images.

Email this | Bookmark this

The very best company to work for in 2005

Every year it is with great interest that I read Fortune magazine's list of the 100 Best Companies. This year, NY based family-run grocery Wegmans is number one. If I were to have guessed the top company, a supermarket wouldn't have been my top pick: afterall past experience is the main ingredient in prejudice. I just don't think supermarkets are the happiest of places. That isn't an uncommon feeling among my friends either. Given, that Wegmans's achievement is truly exemplary.

On another note, it comes as no surprise that California leads the country with the most best companies.

Email this | Bookmark this