I recently read the article How Not to Write FORTRAN in Any Language. It "emphasize[s] form and style ... particularly those features that apply across programming languages". It's an interesting read.

The ACM Queue has a number of good articles that are worth the time to read them.

While doing my morning blog walk I discovered, much to my surprise, that the "early return" is considered "bad practice".

Rather than reiterate all of the dialog surrounding the "single function exit point" debate, I direct you to the following links:

• Single Function Exit Point
• Multiple returns considered bad style ?
• Early Return Style Gauntlet
• Intention...

If my primary language was C/C++ (or any language without automatic garbage collection) then I would agree that an early return is bad practice; it is simply too difficult in most cases to prevent memory leaks with early returns. Since I have shed the albatross of manually managing memory, I have fewer constraints on when I may safely exit a method.

One of my favorite features of Eclipse (and, as usual, I don't care if IDE XYZ supports it) is that I can click on the return type of a method and it will highlight all points at which the method returns (either due to throwing an exception, an exception bubbled up, or a return). See Highlight method exit points for more information. This feature certainly simplifies examining code with early returns.

My personal viewpoint on coding is: reducing the number of factors that one has to be concerned about, in general, reduces the complexity. Reduced complexity tends to lead to code that is less obfuscated, easier to maintain and less likely to contain defects. In order to reduce the number of factors that one has to be concerned about, I liberally employ the Guard Clause which (in most forms) is contrary to abolishing early returns.

But then again, what do I know? I also put comments in my code. *grin*

I recently had the opportunity to judge at a regional science fair consisting of some of the brightest high school students that Chicago has to offer. I must admit that I was simply blown away by some of the work and presentations that the students did. I was quite dubious at first with some of the students believing that someone must have helped them through the majority of the work but after in-depth discussions with them, all doubt was removed.

The rubric for the competition required a the use of a control. A number of experiments involved comparisons in which students simply compared sample A to sample B. Unfortunately this lack a control. Sample A should be compared to the control and sample B should be compared to the control. For some of these experiements it required a great deal of effort to devise a suitable control.

There is one particular presentation that sticks out in my mind that was attempting to show if it was justified to swtich out a batter based on the handedness of both the pitcher and batter. There are four obvious combinations to be compared: left-handed pitcher (LHP) against left-handed batter (LHB), LHP against right-handed batter (RHB), right-handed pitcher (RHP) against LHB and RHP against RHB. But where's the control? Using confidence intervals and other statistics the student showed that switch hitters were representative of the combination of left and right handed batters! The student was then able to use switch hitters as the control. To me, this excercise alone was above and beyond what I expected that actually showing the comparison of handedness was moot.

If you have the opportunity, I recommend that you get in touch with your local school system and offer your time to either mentor these students in preparing their experiments or assist at the science fairs. It is truely a wonderful experience.

The Java Information Group asked the question: if you could pick anyone in the Java community to be your personal mentor for one year, who would that be any why?

Here's my response:

I do not believe that there is a single individual that possesses both the Java and software engineering skills necessary to be my personal mentor. There are those that possess unique insight into Java and there are those that have mastered the mechanics of writing, managing and maintaining Java software but it seems that never the twain shall meet. Though if I had to choose a mentor from the two groups it would certainly be someone that has mastered software engineering.

I have two follow up questions of my own:

1. Do you agree with my observation that it seems that people either excel at being theorists (those that possess unique Java insight) or at being experimentalists (those that have mastered mechanics of writing, managing and maintaining Java software)?
2. Who are the well-known experimentalists today?

In the past I have talked about the difficulties in succinctly defining what a software architecture is. It seems that this difficulty spans over to the role of a software architect.

Below are some links to show how widely the roles and responsibilities of a software architect vary:

• Architecture Roles and Responsibilities
• What are the Duties of a Chief Software Architect?

A comment on Javalobby caught my eye and expresses the root of what It was all a lie was all about:

In this day and age I should be profiting from two decades of code written by brilliant and talented programmers who came before me. I should be able to take advantage of the billions of line of code written to do everything I could possibly think of doing. That was the promise of object oriented programming right? Code reuse remember that?

Instead I have to re-invent the wheel in every language I use for every project I start.

...

I want a better language and better tools. Being a programmer has nothing to do with useless mind numbing work that passes for programming these days. I want my language to enable me to express myself freely and not get in my way, not punish me for making the wrong decision too early....

As I embark on my next project that will require me to duplicate efforts that I know have already been made, I think back to one of the initial promises of OO: reusable objects. When I first started learning about OO many moons ago I was told that there would be this wonderful and vast trove of objects that I could simply pick up, augment and reuse for my own purposes. The unfortunate reality is that there are a precious few objects available.

But why is this?

Off the top of my head a few reasons come to mind.

• Licensing. I have worked in what could be considered to be the "staff augmentation" business for quite some time. All this that boils down to is I typically have very little say or sway when it comes to licensing potentially useful technology. Compounding that is the much feared GPL. Companies run shrieking away from GPL'd software.
• Language constraints. A number of widely used programming languages are severely limited in their ability to augment existing objects. For example, in Java I cannot add a new member to Object that would then be present in all objects. (In theory I actually can do this with AOP but the JVM goes out of its way to make this a nightmare.)
• YAGNI. The whole religion of "you aren't gonna need it" mandates that the objects you create should only have the functionality that they need. By not providing those "well, maybe" hooks, these objects are limiting their own lifetimes and usefulness.
• Lack of imagination. The ability for a developer to think out of their domain is severely limited (and is only going to get worse as each domain becomes more complex). This will limit the potential usefulness of produced objects to other domains.
• Different standards. Different frameworks, different approaches, etc all contribute to objects that are fundamentally incompatible.

This entry was not written to bring about change or to criticize but only to point out some of the road blocks that exist.

Continue reading It was all a lie -- Part 2.

I have read a number of articles in the past few days on what is commonly called "monkey testing". The name comes from the old saying: "A thousand monkeys at a thousand typewriters will eventually type out the entire works of Shakespeare."

• Using Monkey Test Tools: How to find bugs cost-effectively through random testing by Noel Nyman
• Things That Find Bugs in the Night by Harry Robinson (don't forget to check out his "Further Reading" section)
• A Case Study of Coverage-Checked Random Data Structure Testing by James H. Andrews

I felt compelled to do a little research into the origins of the monkey saying and found the Infinite monkey theorem. From this I found the The Monkey Shakespeare Simulator which appears to be a better use for my spare CPU cycles than checking for extraterrestrial intelligence (grin).

In the past I would put as much thought into my next job as I would put into picking out socks. Then I received some enlightening tips from the wonderful people at Stewart, Cooper, and Coon (if you're at the executive level looking for a job or want to make the transition to the executive level, look these guys up -- they're amazing).

Set aside a few hours when you're not going to be interrupted. Go to some of the major job boards (such as Monster.com or Careerbuilder.com) and start searching for jobs that interest you. Don't look at salary, location or experience. Just let your imagination run wild. Write down keywords that sound good to you and use them to help you narrow or diversify your search. You can also write down keywords for jobs that you don't want in order to help you quickly eliminate options.

I found out some interesting aspects of what I would consider to be my dream job that I had never known or thought about before. This process of free association (if you will) allows you to discover much about yourself.

Even if you're not currently looking for a job it is a worth while exercise. Esther Derby has a good article entitled Five New Year's Resolutions for Managers in which she encourages managers to "invest in you" and "create time for reflection". I believe that these strategies are valuable to all workers bot just managers. Make this career search part of your "invest in you" time.

I have been playing around with some UI mock ups lately and it is often that I have code that looks like the following:

    ...
    add(new Label("Some text"));
    ...

If I want to see what Some text looks like in a different color or font then I need to extract the label creation to a local variable and then set the appropriate members. Since I'm a lazy lazy man I was getting tired of this. Luckily I remembered about instance initializers. Because of instance initializers you can do the following:

    ...
    add(new Label("Some text") {{ setFont(someFont); }});
    ...

{{ and }} are not new tokens. Writing it another way makes it more clear:

    ...
    add(new Label("Some text")
    {
        { 
            setFont(someFont); 
        } 
    });
    ...

The only question that remains is: when is the instance initializer executed? You can read section 8.8.5.1 of the JLS if you want. (The problem that I have with section 8.8.5.1 is that it is for explicit constructor invocations which doesn't seem to be the case for this example but I cannot find another reference to instance initializers in the JLS.) The code below provides a clearer answer to the question.

    class PreTest {
    
        {System.err.println("PreTest First");}

        public PreTest() {
            System.err.println("PreTest constructor");
        }
    
        {System.err.println("PreTest Second");}
    }

    class Test extends PreTest {
        {System.err.println("Test First");}

        public Test() {
            System.err.println("Test constructor");
        }
    
        {System.err.println("Test Second");}
    
        public Test(final int number) {
            this();
            System.err.println("Test constructor(" + number + ")");
        }
    
        {System.err.println("Test Third");}
    
        public void method() {
            System.err.println("Test method");
        }
    
        {System.err.println("Test Fourth");}
    }
    
    class Dummy {
        public Dummy() {}
        public void go(Test test) {}
    }
    
    final Dummy dummy = new Dummy();
        dummy.go(new Test(10) {{ method(); }});

When executed, the following is output:

    PreTest First
    PreTest Second
    PreTest constructor
    Test First
    Test Second
    Test Third
    Test Fourth
    Test constructor
    Test constructor(10)
    Test method

An instance initializer is executed during construction but after all other instance initializers and all (appropriate) constructors have finished.

I should point out that this "trick" is also great in unit tests for populating collections.

    ...
    something.addList(new ArrayList() {{ add("1"); add("2"); add("3"); }});
    ...
    foo.addMap(new HashMap() {{ put("1", "one"); put("2", "two"); }});
    ...

A daily work-out is an important aspect of my life both physically and mentally. Throughout most of the year, the facility that I use for my work outs has a natural equilibrium; everyone knows each others cycles and there is rarely a collision where two people want to use the same machine at the same time.

There is one time of year that all consistent exercisers dread: the month after new years. January brings a swell of newcomers into the environment. These bright-eyed newcomers arrive headstrong with the resolution that "this year is the year of becoming fit". After no stretching or warming up whatsoever these individuals load up the weight machines and jerk and pull a few times until they look like they're going to pop and then move to the next machine. They then proceed to the various cardio machines and run / cycle as fast as they can for about thirty seconds until their heart reaches the near explosion point and then they leave (again, without stretching or warming down in any way).

Needless to say this injection of soon-to-be-buff induviduals reeks havok on the natural balance of the workout facility. All regulars recognize the motivation and lifetime of these people and some of us even try to help them prevent from killing themselves. But we all recognize that the number of resolutioners will dwindle to about half by the second week, half that again the third week, and by the start of February there may be a single new person left that becomes a regular.

But why do all of these people fail in their goal? It all boils down to two factors: they lack a detailed plan and they lack domain knowledge. If you would ask one of these individuals why they are there they would likely answer "to get fit". So it is clear that they have a goal (albeit quite loosely defined). If you ask them how do they plan on reaching their goal, they would likely say "I'm going to work out for 50 minutes at least three times a week". That's a good guideline to have but it doesn't actually tell them how to reach their goal. It's also lacking technical detail such as how much weight on which machines or how long with what resistance on which cardio machine. To compound this lack of planning is the lack of knowledge of physiology and the proper use of the available equipment.

This same phenomenon can be witnessed on most projects in low maturity organizations: a general goal is set; people attack the task with wild enthusiasm but little regard for how the goal will be met; within a week or so, half of the individuals are off-task or are already demotivated; in just over a month the first milestones have already been missed or are in the process of being missed; and shortly thereafter, management is engaged to bring the project back into line (the involvement of management introduces a quality cost called a transaction cost). If you ask any member of the team what the goal is, it is likely that they could answer correctly (though I'm always amazed to find people that do not even know the goal). If you ask them how they are going to achieve that goal you are likely to hear a very high level description (or, again, you may find individuals that don't actually know and yet are doing something). It's also common for people not to fully understand the tools available to them or how to best apply them to the task at hand.

Whether you are attempting to fulfill that new years resolution or preparing your next project ensure that you have the basic elements in hand: a detailed plan (including ways to montior if you are on course) and enough knowledge of the environment in which you are working.