It’s Too Big to Be Allowed to Fail

I have been in the middle of a big, self-imposed, programming project for most of the past week. I am embroiled in a project that has become almost a nightmare and it has now hit a stage that I have invested too much time into it to abort the effort. I am jumping ahead of myself so let me catch you up…

Microsoft, .NET, IIS, and J#
A week ago, I was moving code that I had developed to some IIS 64-bit containers. This .NET code was developed depending with JExcel (ported to .NET using J#) for exporting data to Excel spreadsheets. JExcel is a wonderful solution for this since it is compact and has no dependency on Office components being installed on the servers.

Anyway, these 64-bit servers were running IIS 6 and as soon as my code was deployed, it failed miserably and IIS complained it could not load JExcel. After the administrators investigated the issue with me, we determined that even though the .NET code was compiled to be processor-agnostic (32-bit or 64-bit), the J# code was limited to 32-bit only. Strike one!

While IIS 7 permits a container to run in dual mode (32- and 64-bits) simultaneously, IIS 6 can only run in one mode or the other. Converting to IIS 7 is out of the question and moving the entire server to 32-bit mode is not going to happen either. Strike two!

How to Recover?
Ouch! How to work my way around this problem? I have two applications currently ready to move out and there is another application that would benefit from Excel exports in the not too distant future. What options exist for remedying the situation?

Option one is to use Microsoft Office automation but from everything I have read about it, it requires Office to be installed on the computer it runs on. It makes no sense to move user applications out into a server environment, so I would prefer not to go this route.

Option two is to remove the direct dependencies on JExcel within the .NET code and separate it into a service of some sort. I was able to prove that JExcel runs fine on the server as long as it is not within an IIS container. Of course, how to provide this service consistently across the server platforms? It can’t be a web service because this would have to execute in the same IIS container and would encounter the same problem. Create something proprietary? That is not a very appealing option from a support perspective.

Option three is to attempt to port the JExcel from Java to native C# and then compile it natively. This sounds like a reasonable approach for my immediate needs, my future needs, and for the entire open-source community.

A Plan Emerges: Full Speed Ahead and Damn the Torpedos!
I decided to give it a few days and see how difficult a port would be. After all, the benefits to possessing native c# code for JExcel could be very beneficial on so many levels. Two to three days is a diversion from my normal tasks but it certainly can be buffered into my schedule over time. Thus, I started the process of converting each of the 450 or so Java files into C#. This first port would not be an expressly C# application (of course) since time would prohibit excessive rewriting of the code base. The basic plan of attack was as follows:

1. Convert the code minimally to encompass basic C#syntax,
2. Fix the slew of errors the first compiles would pop out,
3. Determine what native C# library classes mimic the Java library classes and can easily be replaced,
4. Determine what Java library classes need C# stubs to massage them into compliance and write these interoperability components,
5. Fix overt Java to C# syntax problem areas such as replacing Iterator with foreach,
6. Test and validate the components.

A wonderful plan, even if I were to say so! Armed with these marching papers, I began the process at the beginning of the week. After almost three days of converting code from Java through a set of SlickEdit macros and finally into Visual Studio, I finally could proclaim that step 1 was completed. Starting step 2, the first compile attempt popped out 4000 initial mostly syntactic errors. These were whittled down over the next day or so and finally the syntax was cleaned up completely. Some of steps 3 and 4 were fleshed in during this stage of development too.

Once the syntax was good, the next compiles generated another 3000 errors. These errors tended to be more serious in nature, visibility issues and glaring problems with library classes. So far, I have invested another half day into working out these issues and addressing steps 3, 4, and 5. It seems so vast still that I was moved to writing this blog entry.

Too Big to Fail….
Remember Fall 2008’s business and banking meltdown? A phrase was coined to support incentives such as TARP (the Troubled Asset Relief Program) in that key banks and businesses were “too big to let them fail.” The basic belief was that the downside to them failing was worse than doing whatever it takes to prevent the failure.

The parallel in this coding endeavor is obvious. I have invested too much time into this already to drop it now, haven’t I? An argument can be made that I have crossed the point of no return and need to complete it. There are not any really attractive alternatives to woo me away from this endeavor, right? Finally, every contact moment with the code ensures that I become more familiar with the codebase so one can argue that each remaining error is easier for me to fix than the previous one.

Yet, on the other side of the coin, I am creating a perfect scenario that illustrates how projects get horribly out of schedule. Consider that I initially thought of dedicating two days to it yet I am now at four days and counting! I can see the Microsoft Project timeline all a-kilter and can hear the angry sounds of a Project Manager (only in my mind at the moment, thank God!). Yet, in my own microcosm, I have imitated the scenario that is the bane of every project!

The question is, “When does one throw in the towel on a project?”

I will give it another day to get into stage 6 or, better yet, to complete the project. If it is not there by close of business on Monday, I will approach my boss with hat in hand and apologize for the excursion into the hinterland and determine what other option can be taken. However, if everything works out well, I will post the code online (LGPL code given back to the community) and move back into the dependent projects as fast as possible….