Something Smells

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?

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: 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. 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. and of course... premature optimization is the root of all evil ! Just a few things to think about...

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 sta...

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...