It works on my machine

One truth I had to come to terms with earlier in my career was the "it works on my machine" anti-pattern. It's a close cousin to the name of my blog - sometimes words DO mean something.

This was back in the days before Windows (yes there was such a thing) and I was writing a custom TSR (terminate and stay resident) module that we used to communicate with the custom database engine we wrote on NetWare (starting to get a sense of the decade yet?). Long story short there was a problem with the code that prevented it from working on one machine - just one. And it wasn't like it always didn't work, it only didn't work sporadically.

In my arrogance at the time, I was slow to take a look at this issue. My arrogant thinking went like (1) this is the only machine to have the issue (2) I spent a lot of time on this code and especially testing it (3) this code has been running on hundreds of other machines without an issue (4) so it must be something particular to the machine or user. Fast forward a couple of weeks and surprise a couple more people report having the issue. It was then that a colleague and I were talking, and I woke up from the spell - "this is something I need to look into" I finally told myself.

Turns out the issue was an interrupt conflict with a badly behaved driver that was slowly be rolled out in a pilot and very soon would release across the entire org and would impact my, now thousands, of customers. Once I figured this out (which was actually pretty hard to do) - the fix was simple; I just switched to a different interrupt. There were other times when I fell under the spell of my own perfume, each time learning something and making me humbler.

Computers and software have grown much more complex since then. developers have much less control over all the code they are dependent upon. In the example above, I was dependent on the CPU microcode, the BIOS and MSDOS - all of which I had the source code for. I could usually discount the microcode (I only recycled the manual last year) which meant that any issue was either with my code or the few dependencies I had. The lack of dependencies and illusion of control was part of where my arrogance came from. But today there are dependencies on dependencies; it's such a complex ecosystem. And yet developers still have quite a bit of arrogance. 

Why am I writing about this now? This time I was the one user for which the application did not work - last year (mid-2020) it started, and I would constantly send logs and traces to the development team, and nothing would happen. I told them that my fear is that my experience was the "canary in the coal mine" and that either (1) other people are also having the issue and not reporting it OR (2) that at some time in the not-too-distant future it would become more urgent. 

The later was this week.

It now works on my machine.

Back-ing into Enterprise Web Applications

Sometimes I just don't know what to blog about. Is it just me? So when I don't have anything I feel is new or original, I guess I need to go back to something old. I know I have blogged about building applications in the browser before. Maybe not on this blog, but certainly on one of the many outlets I have had over the years. This topic has come up again as I consider the implications of technologies like Silverlight 2.0 and AJAX on building enterprise applications.

I really like the browser, but I am not sure it makes a great application platform. It makes me wonder why it seems like we need all these “other” technologies to make it a better platform. Take for instance the Back button. When browsing I am a big fan of the Back button (actually I am still a keyboard kind of guy and I use the backspace key - old habits die hard). Whether you like it or not, I think you will agree it is a standard that a lot of people now understand.

So when I host an application in the browser, what does the Back button do? Or perhaps a better question is what does the user expect the Back button to do? Why would they think it would do anything different?

"Hey, I'm in the browser. There's this big, prominent button with "Back" written on it". Why would I not want to press that?"

As it turns out using technologies like Silverlight 2.0 and AJAX seem to totally ignore this. They ignore it to the extent that you lose a lot of navigation context if you use it. For instance, say I am traversing down through a hierarchy. I get some number of levels deep and I want to
back up to a previous level - hit the back button? Better not if that traversal was being done using AJAX!

By the way this is not an entirely new problem; I first encountered this problem when an application I was reviewing for a client made such extensive use of session that the back button did not do what the users expected. So we spent a fair amount of time and energy coming up with ways to preserve the Back button functionality. First we found some hack that essentially
disabled the back button (ironically, by navigating Forward). Secondly we built our screens such that they used the query string to pass some basic context from one screen to the next; so that when you navigated back the browser would pass all the context back (since all it typically saves is the URL). An additional benefit we got from using the query string was that nearly every page was bookmark-able. The only exception was when you were in edit-mode; we not try to “save” transitive or volatile states.

Couple of side notes... It seems that the Back button works much better in ASP.NET even though the context is not stored n the query string. I have not taken the time to figure out the exact details of how this is working; but I imagine it has something to do with the browser caching pages and VIEWSTATE. Noteto self - go figure this out someday. Found this interesting article to a Java Framework to handle the Back / Bookmark problem introduced by AJAX. I have to imagine that some resourceful person has done something similar on Codeplex (or alike).

There is a time reporting application (to remain anonymous) we use at my current job that makes fairly good use of AJAX. That is in the sense that it does improve the response time and interactivity of the application. The downside is that I continuously get burned by use the back button. Argg!!

On the contrary, the MSDN library site does a pretty good job of mixing the two paradigms such
that when I hit back; the “right” thing happens. Sure, neither of these are enterprise applications (in fact comparing them to one another is hardly fair) but the problem remains.

In my mind I am questioning why we are still using the browser for enterprise applications at all. I know why, but I don’t know why. I mean, the reason why it’s so attractive is that it helps in two major areas; distribution and disaster recovery. Distribution is the whole thing that got
us here in the first place. The DR aspect is something I have been realizing more and more in this post Sept 11 world where DR is something I have to consider more and more. It’s just easy to deploy the web application to two physical sites (managed by some content manager); one the primary and the other the secondary. Give a large enough pipe you can load balance between
the two and have a scalable/HA solution to boot.

By why do they have to run in the browser? Why, why why? Here is what I
propose instead…

1. Build an application as a native Windows .NET application based on a 3-tier architecture. No HTML but some technology like WinForms or WPF.


2. For the middle tier I would like to use something the Entity Framework and LINQ. I have a question as to whether I am going to have a marshalling/serialization issues with this technology.


3. The applications are deployed using something like ClickOnce deployment.


4. In addition, I want to get rid of the requirement to have a specific .NET framework installed. I like the direction the Xenocode people are taking. Basically linking the .NET Framework into your application thereby bringing all the code and the dependencies down as part of download / install.

Just thought I would put some thoughts out here and see what if anyone is
actually listening. Hopefully you also were able to hand on until this point.
Regardless it’s a place for me to vent; kind of like my diary.