Java Hair

Yep, our blog was subjected to hacking and some of the pages were injected with some “badware” links to some suspicious stuff. Sorry for the inconvenience. I’m also sorry that it took so long to find the offending posts. I cleaned up one post and couldn’t find anything else, but apparently I didn’t look far back enough.

I did a bunch of searching and found this wonderful utility, the Bad Neighborhood Link Checker and unlike Google which just said the site had some suspicious links on it somewhere but didn’t specify where, this told me what page had the suspicious links.

My thanks to Michael VanDeMar for making the tool available online and for free!

My last post about frameworks criticized the Spring JDBC Template construct. I don’t really have anything against Spring in particular, I had just stumbled across the JDBC Template a few days earlier and thought it may help make my point. My point, which I attempted to illustrate by that post, was not that the Spring JDBC Template is useless, it is that frameworks in general, which exist to simplify development of complex technologies, by their nature redirect that complexity somewhere else. Hopefully that new complexity is less than the underlying technology and this is often the case. As an architect/designer/developer you should be aware of that the trade-off exists, what the trade off is going to be and make an informed decision.

1.  Configuration Files

Since I used Spring as an example once before, let’s move on to another one of my other favorite frameworks, Struts. Struts has seemed to have fallen out of favor of late, with many developers now hopping on the JSF bandwagon, including our shop. I had to basically be dragged away from it and forced into JSF. However, even though Struts was my framework of choice for years, it had some problems that really bugged me and are issues that still exist today in many frameworks.

One of the nice things about Java is that you can use a smart IDE and it will spot a lot of careless errors for you, especially simple typos. This is important for someone like me who likes to type fast and can tend to be somewhat careless. What I found with Struts is that I often had problems first setting up projects. For some reason I would always end up with a typo in the struts-config.xml file that would cause it to break when starting my application. Struts was never very good at letting me know what the exact problem was and this never ceased to infuriate me, so much so in fact, that one of our products, Rev, was born out of that frustration because it insured that I wouldn’t have to worry about typos impeding my ability to get an application up and running quickly. I continued to use Struts because it’s benefits outweighed it’s difficulties, it didn’t abstract too much of the HTTP layer so I could still understand what was going on pretty easily.

2.  Too much abstraction

Next, for me, came JSF. I actually only started using it because a project we were working on required a technology that was built upon JSF. Once I started using it, I could appreciate how it’s abstraction of the HTTP layer really made things easier for developers, especially for newbies who didn’t really know much about the HTTP layer. All of this abstraction, however, made it difficult to understand what was happening underneath the covers or exactly how it was happening. Some of the simple Javascript patterns I had been using in Struts to solve some common problems became more difficult. Have you ever looked at the source HTML to a JSF-backed page? It’s not nearly as simple and straight-forward as a page developed from Struts. I am still uncomfortable with the fact that I don’t know exactly how to create a request in JSF to accomplish some things seemingly trivial things, whereas the same things in Struts were really easy.

The other problem that I found as we continued to use the framework was that I could have developers who understood JSF and worked in it really well, but they didn’t understand some of the underlying concepts. When something unexpected happened, they weren’t sure where to look. This would occur when a developer’s first experience with developing web applications was with JSF.

That same problem occurs with any framework, since by their nature they abstract the complexity of some underlying technology. This is all well and good until things break. Obviously, Java itself is an abstraction of underlying technology, do I think we’d all be better off going back to assembly language and programming web applications in that? Of course not, but I think as a developer you should be aware of the pro’s and con’s of the frameworks you use.

You should also take it upon yourself to learn something of the underlying technologies so you aren’t completely clueless. I have interviewed plenty of so-called JSP developers who couldn’t tell me what pieces of code were executed on the server and which on the client, who didn’t understand the underlying concept that once your page was executing in the browser, you weren’t able to execute java commands inside a function in a page. I could understand how a newbie might have some problems with that, but an “experienced” JSP programmer?

3.  The Problem with Fixing #1 and #2

Often, with frameworks that become popular, it’s because the abstraction they provide is more useful than the underlying technology by itself and any new complexities it may introduce, it allows developers to become more productive, hopefully much more productive.

In my opinion, Oracle’s new version of ADF, 11g, is a framework that does just that, but it isn’t without it’s share of compexities either. ADF 11g makes a lot of building a web application declaritive. This may be a good thing, but again, you run into the problem of having to deal with many XML files. Oracle alleviated this problem to a very large degree by creating JDeveloper 11g which can handle building and validating the XML files for you. However, now we have a new problem. There are some mismatches between JDeveloper 11g and ADF 11g. In some cases, just because JDeveloper tells you something is wrong doesn’t mean it is wrong and won’t work. This hints at a larger problem: that both JDeveloper and ADF need to be maintained and released on the same cycles. If one falls behind in respect to changes that were made to the other, the usefulness of the collaboration between the two is degraded.

Also, again in ADF 11g, there is a larger issue. That is, if something acts in an unexpected manner, the developer now needs to understand an additional layer of complexity in order to debug the problem. Often the developer will need to resort to asking the experts via a forum or a bug report. Even if the product is open source and the developer could access the code itself, finding and fixing a problem deep within the framework will obviously detract from the usefulness of the framework itself.

None of these “dark sides”of frameworks are reasons not to use them, I use or have-used all of them, these are just issues that you should be aware of and investigate before using a framework. My “issues” (some may describe these as pet peeves) can be distilled into two main items, 1. Increased abstraction often leads to less understanding and 2. Declarative programming creates its own problems.

Obviously we are going the way of more abstraction, not less.  It will be  a great day when we no longer have to worry about the framework we are using breaking and exposing us to the dirty underbelly of technology behind it all.

</rant>

Framework seems to be a pretty hot buzzword these days. Not that it hasn’t been for years, but now more and more clients are asking for frameworks for all kinds of things. Frameworks upon frameworks actually.

The most recent example is a client who wanted a framework that would wrap the way you could call stored procedures via JDBC. I was originally against the idea, but being all about customer service, I know when to give up the fight and just roll with it. What one of my developers ended up creating is a framework that wraps JDBC and allows you to save a few lines of code per procedure call, not bad really, but not really enough to change my mind about the whole thing in general.

I could see why they liked the idea, it did hide some of the perceived complexity from the user of the framework, but the reality was it really didn’t do too much more than make sure the close statement was in a finally block and allow the user of the framework to bypass seting all the parameters in a callable statement.

One framework we looked at using instead of creating our own was the Spring framework’s wrapper for JDBC. I don’t want to start a flame war, but honestly, what’s the deal with that monstrosity? What does it actually simplify? From the examples in the documentation I looked at, it seemed simple enough, but that was only because it was doing simple things. When I took a look at called Stored Procedures it didn’t look so simple any more.

Take the example of calling the sysdate() function from Oracle. This is the code for JDBCTemplate:

import java.sql.Types;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;

import javax.sql.DataSource;

import org.springframework.jdbc.core.SqlOutParameter;
import org.springframework.jdbc.datasource.*;
import org.springframework.jdbc.object.StoredProcedure;

public class TestStoredProcedure {

    public static void main(String[] args)  {
        TestStoredProcedure t = new TestStoredProcedure();
        t.test();
        System.out.println("Done!");
    }

    void test() {
        DriverManagerDataSource ds = new DriverManagerDataSource();
        ds.setDriverClassName("oracle.jdbc.OracleDriver");
        ds.setUrl("jdbc:oracle:thin:@localhost:1521:mydb");
        ds.setUsername("scott");
        ds.setPassword("tiger");

        MyStoredProcedure sproc = new MyStoredProcedure(ds);
        Map results = sproc.execute();
        printMap(results);
    }

    private class MyStoredProcedure extends StoredProcedure {

        private static final String SQL = "sysdate";

        public MyStoredProcedure(DataSource ds) {
            setDataSource(ds);
            setFunction(true);
            setSql(SQL);
            declareParameter(new SqlOutParameter("date", Types.DATE));
            compile();
        }

        public Map execute() {
            // the 'sysdate' sproc has no input parameters, so an empty Map is supplied...
            return execute(new HashMap());
        }
    }

    private static void printMap(Map results) {
        for (Iterator it = results.entrySet().iterator(); it.hasNext(); ) {
            System.out.println(it.next());
        }
    }

}

This is as excerpted from Chapter 11 of the Spring Framework Reference Documentation.

I am positive that if I showed that to the client as an implementation they would ask for a framework to wrap it to hide the complexity and what is the point in that?

The same thing is accomplished just using JDBC as follows:

import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.Date;
import java.sql.DriverManager;
import java.sql.SQLException;

public class TestStoredProcedure {

    public static void main(String[] args){
        TestStoredProcedure t = new TestStoredProcedure ();
        t.test();
       System.out.println("Done!");
    }

    public void test() {
        Connection connection = getConnection();
        String myDate = null;
        try {
            myDate = test(connection);
        } catch (SQLException e) {
            //Might want to do something more useful here.
           e.printStackTrace();
        } finally {
            try {
                connection.close();
            } catch (SQLException e) {
                //don't care right now if we can't close it.
            }
        }
        System.out.println("Date:"+myDate);
    }

    public String test(Connection conn) throws SQLException {
        String result = null;
        CallableStatement proc = conn.prepareCall("BEGIN ? := sysdate(); End;");
        proc.registerOutParameter(1, java.sql.Types.DATE);
        proc.execute();
        result = proc.getDate(1).toString();
        proc.close();
        return result;
    }

    public Connection getConnection() {
        Connection conn = null;
        try{
            Class.forName("oracle.jdbc.OracleDriver");
            conn = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:xe","scott","tiger");
        } catch (ClassNotFoundException e1) {
            e1.printStackTrace();
        } catch (SQLException e) {
            e.printStackTrace();
        }
        return conn;
    }

}

So what was gained with the framework? To me it doesn’t seem like much. I’m not sure where the exceptions went to, do I get a Runtime exception if sysdate isn’t a function? I guess it means the user doesn’t have to access the CallableStatement or ResultSet directly and that *may* be a good thing to some people. IMHO saving yourself from learning JDBC just means that you won’t know what the problem may be when things start to go wrong and you just limited your skillset to a framework that not everyone is going to use.

Many frameworks are useful and I realize this part of the Spring framework is one small piece that probably isn’t used by very many people, but again, that’s kind of my point. Why bother with that piece at all?

I have always fallen on the practical side of technical architecture. I think it is because I started my professional life as a developer and have evolved into more of an architectural role on the projects I work on. I have worked with many architects over the years, though, I’m not sure where their background lies as most of them seem to fall more on the theoretical side of the fence.  It isn’t too often I run across a so-called architect who has the practical side of software down also.

These theory architects are good at writing documents and drawing pictures, and they even have some really great ideas. The downside of these theoretical architects have, is that though they tend to do a lot of research and generally know what all the best practices are, they don’t generally get down and dirty with the tool set and thus don’t know what the real or potential problems are with some of the practices that they suggest.  If there isn’t someone involved in the design who is fluent in the toolset, you could waste a lot of time trying to implement something that isn’t going to work or even just making a lot of small changes that aren’t going to matter in the overall scheme of things.

Regarding this point, I was involved in an interesting conversation with a technical architect on a client’s project recently. This architect is a great guy and in general I respect his opinions and suggestions much more than I generally do when dealing with architect types. However, this time, his tendency to constantly push theoretical best practices over practical approaches was apparent to me and even the client.

In creating an ADF BC layer in JDeveloper, a developer will typically, no always, use the wizard included in JDevleoper (unless, of course, they are using Evo). The way the BC layer is defined, various Entities xml files are created from tables in the database and views are built from those entities. Finally, in what is called an Application Module, the Views are used by defining instances of those views for use in the module. Since these view instances are generated automatically, each view instance has a number appended to it to make it unique. Makes sense, right?

Well, this architect said that it was a “best practice” rename those instance variables into something more meaningful. Now while I agree that it may be nice to rename some of those instance vairables to be something more meaningful, is it really practical, and thus is it really a “best practice” or is it just a good idea?

I interjected that though it may be a good idea, it hardly seemed practical, afterall, if JDeveloper automatically generates the instance names, don’t you lose some of the benefit of the automatic generation when you need to go back and rename all of those instances? At this point, the client joined in the converstation and asked if he had used this best practice in the past.

The architect replied that it is always a best practice to rename files or variables such as those so that the names have meaning. The client asked again, “yes, but do people actually do that in a project? Have you worked on a project in which that was done?”

The architect, much to my surprise, replied with, “well, to tell you the truth, I have never actually seen it done.” I actually had to laugh a little bit. It was actually refreshing to hear an architect say that though something was theoretically a best practice, in reality, it wasn’t done because it wasn’t practical. In a lot of organizations, practicality often loses out to so-called “best practices” many a time. The funny thing was, that in this project, it actually made sense to name our view instances as he suggested, but only because the tool we were using, Evo, would be automatically generating the instance names.

Maybe this article was just an excuse to print one of my favorite Yogi Berra quotes, “In theory, there is no difference between theory and practice. In practice, there is.”

A lot of people ask us where the name Vgo Software comes from. (That’s pronounced Vee-Go Software in case you were wondering.)  Since I’m in Greece this week with a client and I haven’t posted anything in a while, I thought I would expound upon where our name came from.

Back in the day, we were just a consulting company. At that time I had come up with a prototype for what eventually became our Rev product. I remember writing an e-mail to my business partner about this prototype. While writing the e-mail I realized that I did not have a name for the project and started to think about what I would call it.

Earlier that day I had talked to a consultant that was working for us and who was a friend of mine. He told me that he had been experiencing bouts of dizziness earlier in the week and didn’t know what was causing it. After suffering for a couple of days without it getting any better he went to the doctor to see what the problem was. As it turned out, the doctor told him he either had a cancerous tumor in his ear or he had Vertigo.

Thinking about what to name the software, which was a code generator, I thought “Vertigo!” what a perfect name! It generates code so fast it will give you Vertigo. Well, I put that in the e-mail as the name of the prototype and the name stuck for a while but at some point before we actually released it somebody did a name search and determined that the name Vertigo was actually being used by another software company for another product.

About a week later we held our monthly staff meeting where we gather everyone from wherever they may be, talk about current company events, and have beer and pizza. We decided it would be a good time to come up with a new name (esp. after the beer part). After everyone throwing out various names for about an hour, we finally settled on a mutilated version of Vertigo, Vgo.

Well, Vgo eventually became our code generator, Rev, and the product built on top of that which was once referred to as Vgo4Oracle became Evo (anybody notice a pattern emerging?). Both products were part of the “Vgo Software Suite” of products and we eventually just started using the name of the software itself as the name of the company.

Well, it’s one of those weeks for me.  I have about a half a gajillion things to do and one of them includes preparing for a presentation on Monday.  I have had the presentation prepared for a few weeks now and I’ve even presented parts of it over the last month, but I haven’t done any part of the live demonstration yet.  In fact, besides having a vague idea of what I want to show I haven’t really had any time to figure out exactly what the demo is going to be.  Real professional of me, isn’t it?

I had put together what I thought was a solution for a common problem in converting forms to ADF.  I had done most of it on a plane from Connecticut to Austin, TX a few weeks ago.  I didn’t have a ton of time to test it before my laptop’s battery ran out, but it looked like it worked so I was counting on showing that solution during my presentation.  Unfortunately, now, 3 weeks later, and mere days before the presentation I loaded it up again and tried it out and it doesn’t actually work like I had hoped.

So here I am trying to figure out what is wrong with it and get it working, hopefully before Friday so I can run through it on Friday with some of the folks in the office before doing it live on Monday.

It isn’t the usual way I like to prepare for these things.  When doing product demos I have a machine dedicated to the demos that only gets updated when I know it works, especially since it frequently is used to show of “new” features that are in development, I like to make sure I have a script that works and that the environment is always the same.  Too many other things can go wrong to leave any of it untested.

Well, at least if there’s something I’m good at, it’s being able to come through under pressure.  Besides there’s always the flight to Georgia…

Just a quick story from a recent conference we spoke at. At a lot of these conferences or User’s Group meetings there is a question and answer period in which attendees ask questions of all the speakers. The questions I have heard have generally been technical in nature and since most of the speakers are pretty technical, there is a lot of expertise on the “panel”.

At a recent conference, an attendee asked a straightforward Java question. He wanted to know why after sometime of running his Java application, which was a web application running WebLogic, his application would start getting errors from the database that there were too many cursors open.

This is a pretty common problem for beginning Java developers using JDBC and I remember one time about 10 years ago (there I go dating myself again), when I was first working with JDBC I had a DBA come running over to me complaining that I was using up 50 connections to her precious development database. This was my first week at the job and she was an intimidating person. It was then that I learned all about closing connections, statements, and result sets when using JDBC.

Anyway, somebody there on the panel started immediately with “I don’t mean to be rude, but you can’t expect us to answer a question like that without knowing more details about your situation, like what is the application trying to acheive, why is it using JDBC, why are you retrieving a REF_CURSOR…?” and on and on a bit.

I finally managed to get a word in and told the guy, “You should make sure that you are closing your ResultSets and even your Statements in the finally clause of a try/catch block.” This apparently didn’t satisfy the first guy who continued to go on for another 20 minutes about how the every search is now a pagination and it doesn’t make sense to get an unlimited set of results if you are only showing 10 on the screen and how you should really use a PL/SQL Collection to and a stored procedure to return the exact set of results you want, and blah, blah, blah.

I again managed to interupt enough to put in my two cents that if you are forgetting to close ResultSets in JDBC you probably don’t want to bother trying to return PL/SQL Collections yet.

I explained this to my wife, who isn’t technical by comparing it to someone asking a question about cooking, whenever I cook chicken in a frying pan (non-teflon!) it sticks to the pan, what am I doing wrong? to which the simple reply would be “add some oil to the pan first”. The guy I am describing would answer with an entire explanation of why you should bake your chicken instead and insist you can’t get a good answer unless he knew all the spices you were using and the dish you were trying to cook.

I thought it was kind of funny and it was really no surprise that the first guy’s talk was on what? You guessed it…”PL/SQL Collections.”

So, I get this all the time “Why should I convert my perfectly good Forms?”. The answer is you should if you have a good reason to. If you don’t, by all means stay there (until, of course, one day Oracle decides you will not have Forms at all anymore; around 1213 or so, and then you’ll need to do something). I see TON’s of blog’s about the topic. Mostly these entries are on Oracle-centric sites and are not, perhaps, as objective as they could be. So, here’s my opinion on the matter (as I find myself to be a relatively objective person).

Wait, before beginning, I need to pull out a blog-shaped soap box.

These efforts aren’t “conversions”. This isn’t a translation exercise. Meaning, if you think you can change from one computing architecture to a completely different one by pushing a button, you’re nuts. It’s just not realistic. From the outset of Vgo Software (and prior to that, NEOS) we used the word “evolution” or “modernize”. To reach a stage of evolution, you have to work at it to reach the full potential of the modernized state (whoa… I’m feeling a little Zen here).

Think about this, Oracle DBA’s out there: when you upgraded from v7 to v8 of the database, did you use consider the cool new features like partitions, a better cost-based optimizer (though, in my ex-DBA opinions, still not great then) or materialized views (I’m publishing my age here)? If you did, did you get all that stuff by upgrading? NO. You had to reconsider your applications using the DB and what impact that the changes would have on them. 

I shouldn’t mention that your manager wouldn’t give you time to implement any of the good stuff as I’m sure that wasn’t/isn’t common at all.

So, back to Forms and Java.  The people that should want to convert would be those folks who want to integrate applications in a standard way.  They want to move towards service orientation and can see integration across application silo’s.  These folks may want to move away from Oracle as an application solution and move toward open-source, allowing them to use a wide community of development resources.  Of course, Oracle has been making great strides as we can attest to. 

But why is Forms evolution hard?  It’s hard because there is alot to do to create a solid JEE app.  In a code translation (of which there are a large number), an engine maps each construct to a “Java equivalent” which may, or may not, be proprietary to the translator.  What you do in those cases is create at least 2 different source files (possibly 10 times more) for every Forms program unit, trigger, etc. creating a huge mess.  Maybe it works, most likely it will not, but then your stuck with 1 million source files and no way to maintain them.

We put in a lot of effort to try to allow people to clean up and consolidate code in forms applications (we’re the only one’s who do that, BTW) and even build customized classes from existing forms components.  Our last release allows you to do this across different forms applications, creating true enterprise-class applications and services.

There is also discussion about modernizing Forms apps by putting all of the PL/SQL in the form into the database (perhaps the re-surgence of mainframe computing is making it into the distributed database market).  This approach was taken by forward thinking companies in the mid-to-late ’90’s by taking core business rules out of their forms and wrapping them in CRUD procedures in Oracle to thin out the front end.  A good approach back in the client/server days.  In fact, I did that myself with a large annuities application.  But now you have application servers that run real Java; why would you want to isolate your business logic in a single database?  What about sharing that logic with other apps (yes, I know you can do that to some degree in Oracle)?  What about exposure as a web service from different platforms?  And how many PL/SQL programmers can be found to manage really large apps that stuff all of their logic in a database?  In my opinion, fattening the database isn’t a viable architectural solution in this day and age.  If you want to thin-out your front end, that’s great, just don’t dump all of it in the database. 

So, I’ve written this over a vast amount of time, being a poor blogger (Rob may suspend my blogging privileges after this release).  Maybe it’s insightful to you; therapeutic to me.

There are many things that a good developer should know, especially when developing web-based applications for large companies, probably even for smaller companies. When I am looking to hire someone with experience, I usually have a few prerequisites. Here is my short list of those things.

1. SQL and more (PL/SQL, Transact-SQL etc.)

Learn to write a query in standard SQL. If you are a developer, especially these days, all of that crazy SQL code may be masked by some sort of ORM layer, but if you have the opportunity or can make the opportunity, learn some SQL. It comes in handy when you are unit testing your persistence layer or trying to find test cases that meet certain criteria. I know you are a developer, but you may be asked to do these things every once in a while.

2. Database Administration

Learn enough database administration to be able to set up a development instance of a database on your own machine. Know how to create indexes and constraints. You can get copies of virtually any database for development purposes legally and for free, so do so and learn the basics.

3. Linux or Unix

Download a few distributions of Linux or if you have access to Unix systems, use that access to learn a few things. Learn how to get around in the file system. Learn how to change permissions on files, do searches, download and install packages and if you are brave enough, learn how to compile some downloaded source code.

Learn a shell scripting language and gain at least a cursory knowledge of grep, awk, and vi.

4. Perl / PHP / Python

If you are developing Web applications in one of these languages already, then ignore this, you already know it (obviously). If you are a Java developer, keep reading.

Learn one of the P’s. Sometimes you come accross things that are much easier done in a script and may be possible in a shell script, but lots of times these things are easier in a language like Perl, PHP, or Python. If you get really brave, build a simple website in one of the P’s, probably not Perl.

5. TCP/IP

Learn what TCP/IP is. Learn how the internet works. Know what DNS stands for. Basically learn enough so that if you get a new laptop you aren’t pestering the system admins for the first few hours because you can’t connect to the internet.

6. HTML/CSS

Often times you will need to do some basic styling on your pages. Make sure you can read HTML source code (and who can’t these days? Even my cat has a blog) . Know some CSS, nobody is asking application developers to be web designers, but being able to make some simple changes to make your application look good is nice knowledge to have.

7. Javascript

Every non-trivial web application is going to require some javascripting and don’t expect an HTML-wizard to be able to help you out. Most of the time the javascript you’ll need to know is outside of their experience. With JSF frameworks and tools like ADF and JDeveloper, the amount of Javascript you’ll need is less and less with every release, but at some point you will find the need. Plus once you’ve learned Html/CSS and Javascript, think what you could do to your Facebook page

8. Troubleshooting

I think what might be the point of all this is that as a web application developer, many, many things can go wrong. Applications aren’t all built in C anymore, they consist of Javascript / HTML / CSS / Some-server-side-language-of-choice / Probably an Application Server or HTTP Server / SQL / and a database. If your page isn’t displaying, you need to know if it is because you have an error in one of your components or if your query didn’t return any data.

If you don’t have the opportunity to learn such things on the job, then find a cheap machine in a junk pile somewhere, install a linux distro on it along with a database, the Apache web server, and a decent version of Perl and go nuts. I am always disappointed if I ask a potential candidate if they have Linux installed on a machine at home and they say no. If they say yes, it’s a plus, if they say yes and it is installed on their Wii, then I hire them on the spot.

That’s my list. What types of things do you feel a Web Application Developer needs to know these days?

On a recent customer visit to Greece, I had the opportunity to meet some great people and learn some interesting things. One of the more memorable experiences was with talking to our gracious host, who, like all good Greeks, was hospitable enough to make sure that we were treated to all different types of Greek cuisine during our one week visit.

At one of those meals, the first one, actually, we realized that no matter where you go, the relationships between men and women are the same. No wonder, that Men are from Mars book was such a great seller. Later in the week, after the relationship coversation, our host took us out to dinner with his wife. Once again the subject of husbands and wives came up. Ernst made the comment that his wife is a firm believer that if you take clothes out of the dryer as soon as they are dry, there is no need for ironing.

The lone woman at the table had the response that it is true that if you take the clothes out of the dryer as soon as the dryer has finished its cycle, the clothes will not be as wrinkled as if you had left them in the dryer. This prompted the statement from her husband, our host, that her comment was “logically truthful, but practically useless.”

I’m not sure if it was the Ouzo or the Greek beer, but that prompted quite a few laughs from the men at the table.

Recently, I took a look at some code that came back from an offshore company we had work on a small project for us. It is a fairly straightforward web application, but I knew from talking with the offshore project manager that it wasn’t going to work out. Thankfully we had worked out a kind of trial deal where the work they were performing was minimal and cheap, if not free.

I first knew we were in trouble when I kept insisting that since they got started 2 weeks late and I knew it was at least a 3 week effort that it wouldn’t be done on time. I insisted but the PM kept saying “Yes, yes, it’ll be done, no problem.” Well, needless to say, it wasn’t done. After another couple weeks of their effort on it, the project ended and I decided it would be best to tackle the rest in-house.

Well, I finally got a developer to look at it, and parts of it are surprisingly good, so it wasn’t a total loss. Other aspects of it, though, make me shake my head in wonder.

The developer who was fixing up what we got back called me over to take a look at some validation logic on the server-side of this web application. The original off-shore developer had coded the validation messagees to pop up using JOptionPane, such as “JOptionPane.displayMessage(”This is an error.”);” The thing is, if you know nothing about web applications, and they had assured me that they did, this may actually appear to work if you are testing the application with a browser and a server on the same machine. The JOptionPane call causes Java to pop up a message box with the desired message in it, but this is coming from the JVM on the server, not from the browser.

The developer I had looking at it, who admittedly, is pretty inexperienced, asked me why the alerts were sometimes appearing under the browser window. We opened up the code, took a look, and found the offending code. Without saying anything I asked the developer to test from another machine, and low and behold, the error message would pop up on the server. Not only did the message pop up on the server, but it is a modal dialog box, so the thread would stop processing until someone responded.

I don’t think this is what was originally intended, and I’m sure when that first developer unit tested it, the error messages popped up as expected, but everything certainly wasn’t as it appeared.

So now when people ask me about offshoring and the savings involved, I look at the rate sheets of offshore companies compared to ours and I have to say, “Is offshoring a feasible way to save money on a development effort? Logically, yes, but practially, it’s useless.”