COBOL.Net is NUTS!!

Just read an article about COBOL.Net.....who would really want to subject themselves to this horror.

Let's take the sample code in C#:

private void button1_Click(object sender, System.EventArgs e)
{
   button1.Text = "Call COBOL";
}

Now here is the same method in COBOL:

METHOD-ID. button1_Click PRIVATE.
DATA DIVISION.
LINKAGE SECTION.
01 sender OBJECT REFERENCE CLASS-OBJECT.
01 e OBJECT REFERENCE CLASS-EVENTARGS.
PROCEDURE DIVISION USING BY VALUE sender e.
   SET PROP-TEXT OF button1 TO "Call COBOL".
END METHOD button1_Click.

Am I the only one that finds this maddening. OK, OK, for the record there are still more lines of COBOL running then any other language. It could be that COBOL is just that great or it could be the fear of re-engineering systems are working just fine.

Any thoughs?

Refactoring: Means versus Ends

First, I see 2 reasons to refactor:

• Improve performance
• Make code easier to maintain (and extend)
  

Most other "reasons" that people use to justify refactoring are only a means to one of the 2 ends stated above. If you aren't ultimately reaching one of those ends, then reconsider refactoring. If your changes are to the detriment of one of these 2 means, then don't refactor. In fact cargo cult refactoring can be more harmful than helpful.

Think about these:

1. Not all duplication is bad. Some blocks of code are more self explanatory then an oddly named method that wraps it. Saving 6 lines of code may come at the cost of flexibility and higher levels of coupling.
2. Overly abstract code can become highly unmaintainable, even cryptic. In an effort to write more concise code we inadvertently write less concise code. Specialization can be a good thing. Astronaut APIs can be bad.
   
3. and of course...premature optimization is the root of all evil!

Just a few things to think about...

Ridding Your Garden of Bugs: Gardening the Backlog

I'm not sure if I agree with this "article" but, it is somewhat related to a discussion my boss (Dr. Rob Miller) and I were having earlier today. Ideally, we would like to focus every third (I just picked a number) release on "bug hunting" or finding and fixing bugs. Unfortunately, bugs are often a debt we live with for a long time, in the face of progress and new features. I have known few products that didn't have some glitch and the promise of new features often takes some of the edge off of these glitches.

Conversely, some bugs can leave users with such a bad taste that they never quite trust your software again. In the article above the author describes a bug that was reported fixed but still remains broken....after 2 years. Furthermore, as more bugs slip through the cracks a system can slowly become more and more unstable.

This suggests that, when planning product releases, stakeholders should balance the need for new features with the need for a stable system. I believe that, by better "gardening" a product's backlog, most products can avoid these pitfalls. So, here are a few points to consider when gardening your backlogs:

• Are stakeholders keeping and gardening personal backlogs? When I say, "personal backlog" I am referring to the features, enhancement and bugs that each stakeholder or program manager would like to see implemented. At every release planning meeting these "personal backlogs" should be gardened and brought to the table for consideration in the "product backlog".
  
• What have users been promised (explicitly or implicitly) and what is the impact of leaving those promises unfulfilled?
• Do you know how "real" users feel about your software? How do you collect this information? Sometimes, we get ONE very vocal user (see above). Sometimes we have a quiet majority. When should a user's/client's opinions impact the requirements for a release?
• When is a "bug hunting" expedition called for? Is there some threshold or event horizon? Do we have a good litmus test?
• Finally, is there a single decision maker (the one ringable neck) for the product backlog? Someone to take all of the personal backlogs and prioritize them. In XP this would be the On Site Customer and in SCRUM this would be the Product Owner. I suggest that it NEVER be your development team. This person maintains the backlog, the vision and the roadmap.
  

 It's not likely that you will squash all the bugs in any non-trivial system without writing some questionable code. So, you should take the time to test drive your software. Also, watch others "test drive" your software. This advice is not just for developers. In fact it's doubly important for non-developer stake holders and Decision Makers to "test-drive" the software. Kick the tires, check all the instruments. How's the suspension? Is it idling rough? Take it to a mechanic (engineer) and see if any maintenance is due (technology debt). Next time you prioritize your backlog you may have a different perspective.

Taking the time to garden your backlog will leave you smelling like roses. While just letting things grow out of control could have you digging in the weeds!

Profiling Nhibernate

I recently purchased 4 licenses of Ayenda's excellent Nhibernate Profiler for my office. The tool truly is amazing. The real time metrics provided by the profiler have already helped us improve the performance of our applications and identify some not very efficient database calls.

Here are a few features that we really like:

• Realtime view of queries being sent to the database. This information includes a stack trace and properly formated SQL! You also get to see if the entities were pulled from the query cache, level 2 cache or directly from the database. The SQL view can really expose some nasty databse calls.
  
• Number of sessions opened. The queries are broken down by session. You can see how many queries each session makes and a mirad of statistics.
• Unique Query statistics. NH Profiler offers an aggregate view of how often each query was called and the average time it took. This is invauable information for improving performance.

This tool offers a ton of other features that we haven't even touched. If you use Nhibernate or ActiveRecord (as we do) I highly recommend you pay the fee and get a copy. You'll also be helping out a brilliant programmer (Oren Eini).