Sharp stuff

If something is math-related, it's unreadable. Long live C#, die F#, die LINQ. I ain't fucking touching anything with lambda in it.

ROI for WCF and WF

This spring I had a lot of time and no job. So I was lying on the floor, weighting the possibilities: I could become a bum, sell my yacht, dig deeper into Windows Workflow Foundation (WF), or I could go with Windows Communication Foundation (WCF). I had all the books I needed to decide -- three on WF, two on WCF. I carefully looked at those books, read all the introductions inside, and it became clear to me that WCF had a better return-on-investment (ROI). First, books about WCF are 20-30% thinner than those about WF (you invest less time). Second (you get more possibilities in return), WCF seemed to be more valuable for a whole lot of my possible employers: I think WCF-services will become no less popular than web-services pretty soon, and WCF is a unified platform (there are limitations) for building distributed applications. Those are in high demand these days.

WF, on the other hand, provides a unified platform for running and designing workflows, for automation of business processes. If you decide to spend time learning WF, you will end up with business process logic decomposed into workflows, which are made out of activities. If the design will be ok, you will be able to get the stuff automated with less software developers and more analysts. But it's not clear to me who would want to translate business logic from, say, pure C# to a well-designed workflow with corresponding activity libraries (let's assume those will also be created with C# code) -- the effort required to do the job is substantial. At the same time when you're migrating from, say, a web-service to a WCF-service, almost all code just stays the same in majority of scenarious.

I must also note that if you want to automate business-processes, all you need to know is C#. That's a great unified platform by itself. WF adds value, but increases costs, while WCF adds more, and it decreases costs, as it really provides a common model for coding distributed applications. WCF isolates you from excess information to a degree: you don't have to be intimately familiar with ASMX, WSE, MSMQ, IIS or whatever to start creating distributed applications, all you need is WCF (and an experienced architect). Therefore, WCF seems to be more newcomer-friendly and a great investment.

In short, I'm sure it takes longer to see the benefits of WF in action, than it is with WCF. I may be wrong, and I haven't covered all bases here, but that's what I was thinking while choosing between WCF and WF.

P.S.
Maybe WPF or Entity Framework, or another fancy new thing is great too, but it's out of my area of expertise. And for me it's one thing at a time.

P.P.S.
I had some experience with both WCF and WF, when I was lying on the floor.

Usage Errors and ArgumentException

I'm a bit defensive when I write software. I'm careful with the preconditions in every method and I always validate arguments of all methods. So I throw ArgumentExceptions a lot. The question is: should the code, which is calling into my code, catch and handle those exceptions or should it let the CLR kill the executing process by letting the exception propagate to the top of call stack unhandled? Many people say it's a good idea not to catch ArgumentExceptions, because those exceptions usually indicate usage errors, therefore, erroneous code must be recompiled, retested and reshipped. I am not sure about this idea being good. Why should everything crash if a method is has been called with improper arguments? The logic that acts as the argument guard must precede any business logic in a method, so if you get an ArgumentException it also says that there is no inconsistency in the system state (there is -- only produced by callers up the stack). So I catch ArgumentExceptions, log them, send error reports (optionally), recover from those exceptions (fixing inconsistency produced up the stack, if any) and continue running the application.


Yes, maybe you get an ArgumentException because a subsystem (a piece of logic, a function, a feature) is not working in the current release. So be it, maybe we should turn this failing feature off then? -- after we get a certain number of similar exceptions? Yes, this requires a bit of management, domain expertise, and some architectural effort, but I, as a user, fucking hate crashing applications.


Take a text processor for example. Imagine that every time you click «File->Save as…» in the menu, a usage error occurs, an ArgumentException is thrown -- should we close the application and report an error, or can we report the error and continue running the application? I vote for option #2: nothing critical has happened, and I would prefer either just logging the error, reporting it or blocking the erroneous execution path for the release (e.g. by disabling the menu item) to closing the app, losing the document that the user had been editing and then trying to recover it.


P.S. of course, there are ArgumentExceptions indicating that the application is unusable -- it depends on which component throws and under which circumstances.


UPDATE: I have changed my opinion three months after posting this. I do prefer to not catch ArgumentException-s.