Sonu Arora has a great post on what exactly the WCF LOB Adapter SDK does and how it relates (i.e. extends) the capabilities of the normal WCF channel and extensibility model. Her entire blog is worth checking out if you've been wondering just what the fuzz is about, particularly since now a Release candidate of the SDK has been made available to the public.

WCF LOB Adapter SDK

Some things I've noticed while using Visual Studio 2008 using the downloadable VSTS VPC image:

• The IDE, in general, seems a bit snappier than what VS2005 is for me. This is good news, and I do hope it keeps this way.
• Contrary to what I expected, the Workflow designer is not snappier. It feels significantly more slow than in VS2005. This is bad news, considering it isn't snappy by any means in 2005
• Can somebody, please, put the stupid Task window out of its misery and stop bugging us with it? It used to pop up at inconvenient times in VS2005, still, but it keeps popping up all the time in Orcas. Extremely annoying.

Visual Studio

One of the new power features in .NET 3.5, sorely missing when .NET 3.0 was released is the integration between Windows Communication Foundation and Windows Workflow Foundation, in the way of the new Workflow Services model. Besides providing an easy way to invoke WCF services from WF without resorting to using BasicHttpBinding on the services or invoking a [wrapper] client class form a code activity in your workflow, it also provides a way to expose a workflow as a WCF service to the outside.

The second functionality is the one that, naturally, interests me the most. After looking at it for a while, I've made a few observations that I'd like to share.

Implementing Services

A very interesting thing is how you implement services as workflows. If you know how to create WCF services the right way, then you [mostly] know how to implement services as workflows. The reason for this is that most of the tasks you'd normally when creating a WCF service still apply when creating a workflow service. That is, you will still declare your service contract (interface) as well as your message/data contracts. The only key differences really is how you implement that contract.

When using workflow services, you implement a contract by using the new Receive activity introduced in .NET 3.5, and select which operation of the contract you'd be implementing. You still need to do the activity binding dance for parameters as well as (possibly) create response messages for the incoming requests. Basically, the Receive activity works as a kind of sequential activity where the child activities represent the tasks to execute after the request message is received until the response message is sent (if this is a request/response service).

You'd also need to do a lot of the usual work in setting up your service host, only instead of using the regular ServiceHost class you'll be using the new WorkflowServiceHost class. Guy Burstein has a good entry on getting started on exposing workflows as services here you might want to check out.

Starting Workflows

One very interesting option in the Receive Activity is the CanCreateInstance property. You can use this property to have the WorkflowServiceHost automatically create and start a new instance of your Workflow when a new message arrives at the service endpoint for the implemented operation, without having to write manual code to receive the message and create the new workflow instance.

People familiar with BizTalk 2004/6 will recognize this option as being similar to the Activate property of the Receive Shape in BizTalk orchestrations. It also serves, in a way, a similar purpose as the CanCreateInstance property of the new [DurableOperationBehavior] attribute introduced for WCF in .NET 3.5 as part of WCF Durable Services infrastructure. Jesus Rodriguez has an excellent article introducing this new feature.

Something I found a bit curious about the CanCreateInstance property of the Receive Activity is that there's currently no validation around where you set it. As far as I can see, it doesn't make much sense to use it unless the receive activity is the entry point of your workflow, but currently nothing prevents you from setting it if is not. That said, I guess it might be difficult to validate this correctly given the WF execution model.

Continuing Workflows

The Receive Activity doesn't limit you to starting new workflow instances; it also allows your workflow instance to wait until a message is received (through a service invocation from a consumer) to continue execution. This is a key scenario for long-running processes because the workflow will have all the necessary context within the business process to interpret the coming message correctly and act on it.

How does the host know which workflow instance should process a given message, then? The answer lies in the binding context. WF requires the consumer of the service to send a token alongside the request message that tells it what workflow instance the message is for. This token is, essentially, the WorkflowInstanceId, and can be sent either as an HTTP Header or as a SOAP Header.

Using the WorkflowInstanceId as the instance selection token is a logical choice for WF, as the Workflow Runtime, as well as the persistence service, already have clear knowledge of what the ID means and how to use it, so getting the right workflow instance to pass the message to is basically just a call to the GetWorkflow() method of the WorkflowRuntime object.

For this entire process to work, both the server and the client must use the special WSHttpBindingContext class, which helps makes this process a bit more transparent (particularly for the workflow service). On the client side, naturally, the service consumer must be, somehow, aware of the correct workflow instance ID to use as the token. Sometimes, this will be handled in a very transparent way by the infrastructure, but sometimes you'll need to make it more explicit. And by the way, the WSHttpBindingContext class is also used for WCF Durable Services.

Serge Luca has an extensive sample of using WF Services in several scenarios that is pretty interesting to check out.

The Limitation of IDs

This entire mechanism works fine for WF Services. However, after I saw this the first time, there was something that I didn't quite like about it, and it kept nagging in my head. A few days ago I finally realized what it was: As a first option for having this feature, it is pretty useful, but it is, in a way, a significant step back.

The problem with using the WorkflowInstanceId as the linking element between the service consumer and the workflow implementing the service is that it has, essentially, no business meaning. While it is a very useful technical discriminating ID, most business scenarios where this kind of long running services and processes are involved already have natural correlating identifiers in the problem domain, like a purchase order id, a loan id, or a combination of customer id and tracking id.

There are several implications of this simple fact:

• Consumers of the service become aware of the fact that there's a workflow on the other end of the service. This is actually merely an implementation detail of the service which should be transparent to the consumer as much as possible.
• Consumers might now be forced to track yet another id, and one that has no business meaning at all. So instead of just having, say, the order id around they also need to find where to store the workflow id.
• The WorkflowInstanceId becomes an added part of the service messaging, but it is one you might not always be aware of because it doesn't make part of the core messaging description.

Of all of this, I think the second one is what bothers me the most. If you're ever used the wonderful Correlation Set mechanism introduced in BizTalk 2004, then you'll definitely see where I'm coming from, as this is a bit more restrictive and less expressive than what we can do right now with BizTalk. In fact, this is more akin to the limited correlation mechanism we had back in BizTalk 2002 (though that required jumping through a lot more hoops).

Conclusion

All in all, this seems like a very welcome addition to both WCF and WF, even though there are limitations in this first release. I'll be watching closely how both develop as they take a bit more of the core messaging and orchestration strengths that Biztalk has enjoyed for the past few years.

Workflow, Windows Communication Foundation, BizTalk

Udi Dahan posted a few days ago an entry (rant?) on Web Services as an interoperability option between .NET and Java and the potential pitfalls in that. Based on my personal experience, I can't help but agree with him that there's still a ways to go.

Now, don't get me wrong; using Web Services is still simpler in many cases than the other options available, but it's no silver bullet. More to the point, interoperability is not something you get for free; it's something you have to architect, design, code and test for.

Here are some (random) observations on this from my own personal experience:

Know who your clients are and what tools they use

Sometimes you will have to make trade offs in the design of your service contract based on who your service consumers will be and what tools they are using. In an ideal world this wouldn't be necessary, but alas, that's not where we live. For example, Java tools tend to favor certain specific patterns. Or maybe your consumer will be an integration tool or maybe even a legacy platform using one of the many, lesser known SOAP stacks available. Those usually have specific restrictions.

If you know your consumers will be using Java, try to find out what specific SOAP stack they are using (from the plethora available for Java) and explicitly test against it. It will be a worthwhile use of your time. If your consumers are LOB applications, modern third party packages with built-in WS support, or desktop applications (i.e. MS Office) then again special restrictions might apply, so try to find out before hand.

Understand SOAP Encoding and Messaging Patterns

A lot of people still don't know the difference between SOAP RPC/Encoded and Document/Literal. Microsoft took the initiative back in 2001/2002 when the .NET ASMX stack turned on Doc/Literal encoding by default (a wise move, imho), but Java toolkits took a long while to catch up.

Even today, a lot of Java toolkits will default to RPC/Encoded even if they support Doc/Literal and, unfortunately, a lot of Java developers don't know their kits well enough to turn on the right settings. To be fair, a lot of .NET developers don't know how to change the encoding settings either, but we forgive them because of the sensible defaults in the platform

Know the basics

Study and learn how to apply the basics of the WS-I Basic Profile in your platform of choice. Take good care in ensuring you follow the basic guidelines for service/message contract design, and learn what options are available in your platform to control service and message generation.

Here are some good resources to keep in mind for .NET:

• How to Apply the Basic Profile
• Building WS-I Basic Profile Compliant Web Services using ASP.NET 2.0

Beyond the Basics

If you thought interop with plain old SOAP (POS?) could be hard, then be double wary when you get into the WS-* specs, which are sure to complicate things further and bring a lot of extra interop challenges. WS-Security and its related specs, in particular, can give you some nasty headaches. Some thing to watch out for:

• Again, check which toolkits and clients your consumers will be using. Make sure they support the exact protocol versions you expect to be using.
• Make sure you've tested interoperability using the specific protocol features you expect to use. For example, if you're using WS-Security, make sure you can interop at a basic level with the message confidentiality, message authentication options and token kinds you plan to enable.
• WS-Security interoperability problems, in particular, can be nasty to diagnose because most implementations throw extremely uninformative error messages that don't tell you much. Yes, even WCF falls into this trap.
• Watch out for interrelated specs in use. For example, when using WSE to add advanced security to your services, it would by default add a bunch of WS-Addressing stuff that caused extra interoperability issues, because there were several [incompatible] WS-Addressing versions. Add to this that WS-Security was a lot farther down the standardization path than WS-Addressing.
• Know your platform limitations: If you're using .NET 1.1, then you've got very limited options (WSE 2.0); If .NET 2.0/3.0 then at least you have a much more modern WSE 3.0 and WCF options at your disposal.

One hand giveth, the other taketh away

If you're using WCF, understand the choices it makes for you and how to work around them. For example, Data Contracts in WCF aim to improve interoperability by severely limiting the kind of XML structure you can use (elements only and so on). This, however, doesn't help you if you have to work with specific schemas designed by someone else (like standard industry schemas), so be ready to fall back to the old trusty XmlSerializer.

Another thing that might impact you is WCF's default behavior in generating split WSDL descriptions where the schemas are imported (and possibly other WSDL documents as well if your service elements have different namespaces); a lot of external tools choke on those service descriptions. Again, let me point to Christian Weyer's excellent article and code sample to ease the pain of this.

Web Services, Interop

One of the things I've been missing while using Vim lately that I relied a lot in other text editors was a decent status line. in particular, I really wanted to have the current line and column number. I've customized my vim installation before, but had not found quite how to configure the status bar to my liking, until I ran into this sample vim script.

Here's the relevant script section: 

" Custom status line display
set ls=2 " Always show status line
if has('statusline')
    " Status line detail:
    " %f		file path
    " %y		file type between braces (if defined)
    " %([%R%M]%)	read-only, modified and modifiable flags between braces
    " %{'!'[&ff=='default_file_format']}
    "			shows a '!' if the file format is not the platform
    "			default
    " %{'$'[!&list]}	shows a '*' if in list mode
    " %{'~'[&pm=='']}	shows a '~' if in patchmode
    " (%{synIDattr(synID(line('.'),col('.'),0),'name')})
    "			only for debug : display the current syntax item name
    " %=		right-align following items
    " #%n		buffer number
    " %l/%L,%c%V	line number, total number of lines, and column number
    function SetStatusLineStyle()
	if &stl == '' || &stl =~ 'synID'
	    let &stl="%f %y%([%R%M]%)%{'!'[&ff=='".&ff."']}%{'$'[!&list]}%{'~'[&pm=='']}%=#%n %l/%L,%c%V "
	else
	    let &stl="%f %y%([%R%M]%)%{'!'[&ff=='".&ff."']}%{'$'[!&list]} (%{synIDattr(synID(line('.'),col('.'),0),'name')})%=#%n %l/%L,%c%V "
	endif
    endfunc
    " Switch between the normal and vim-debug modes in the status line
    nmap _ds :call SetStatusLineStyle()<CR>
    call SetStatusLineStyle()
    " Window title
    if has('title')
	set titlestring=%t%(\ [%R%M]%)
    endif
endif

And here's what it looks like:

Vim, Text Editors

I downloaded the Safari 3.0 for Windows beta last week. Not that I'm particularly interested in moving off Firefox right now, but I thought it might be a useful testing tool for those rare occasions I do web development.

Unfortunately, it hasn't proved very successful yet . With the original build 3.0.1 I got bitten by the "no text except in Apple WebSites" problem. A quick examination revealed that Safari refused to render any text in a font different from Lucida Grande (now, that's a nice font, but this might be taking it a little too far!).

So I downloaded build 3.0.2 yesterday, hoping it would fare better. Nope, no such luck. This one crashes hard during startup:

Safari

Nick Malik has posted another thoughtful piece on the whole Mort topic that's been going around these past few days. While I appreciate where Nick is coming from, I can't agree at all with his perception. Ayende also voiced his opinion on the topic here.

Trying to control and bound a developer and intentionally doing everything possible to keep him blissfully ignorant about the tools he's working on has not proven very successful so far, and frankly, I think it's not only a bad idea (as in, it doesn't work at all, abstractions are leaky and all that), but I also find the idea incredibly depressing and dreadful.

Here's just a few things that are incredibly wrong with this whole idea, imho:

• It is a self-defeating attitude: It means you stop focusing on improving the situation and purposefully keeping it in a bad, unsustainable position.
• It is really elitist, far more than any of the times the whole ALT.NET idea has been brought forward. It essentially means you just split the developer profession in two mutually exclusive, segregating communities (casts?): Those that know and do, and those who don't know and do.
• There's no way to cross the bridge: Once you've started as one of these Morts guys, you stay there. The whole proposition is based on the idea that Mort has no need to learn anything new on the job (and possibly didn't even need to know much to start with). Indeed Mort should not try to learn anything or become smarter lest he tries to work around the walls of his prison (thus causing damage).
• This, in effect means that once a Mort, always a Mort. Mort is not likely to look for a new work place, since he'd only be able to work as Mort anywhere else, anyway. No need to keep working hard trying to attract and keep those pesky developer types, whooohooo!.

Incidentally, this is why this whole idea is the wet dream of most project managers and IT shop owner's I've met: it promises cheap, untrained, replaceable labor, and low cost to ensure high personnel retention. Goodness gracious great balls of crap!

Now, is it good to try to make it easier for the developer to focus on solving the business needs? Absolutely. Is it good to try to raise the level of abstractions we work for so that we can concentrate most of the time in the parts of applications that actually matter? Again, absolutely agree. But making the leap from here that the obvious end result we should aspire to is to this? I mean, if that's the best we can do, we might as well just abandon all hope and give up.

An interesting aspect of Nick's proposition is that it is indeed a win-win situation for a company like Microsoft, while I'd say pretty much all IT shops (partners) in the MS ecosystem would come out loosing.  See, in Nick's ideal world, Mort would just drag and drop till he drops (sorry, couldn't resist ), while someone smart would create the tools and services he use. The next proposition in line would be that those tools would be done by MS (of course) and the services well, by none other than MCS [1]. Partners around could put in those Morts instead of supplying development talent, but, well, what do you know! Since Mort doesn't really have any special skill set (particularly none that's very software specific), well, the business themselves might decide to supply it! [2] 

And now we've just gotten round all the way back to the old idea of CASE tools and 4GL languages.

[1] I have no grudges against MCS; indeed I know many people working there. It's just the logical conclusion

[2] This would also likely mean that those lucky enough to actually work on the Developer side would probably be able to get paid a lot more for their work, being a scarce resource and all...

Software Development, Morts

In my previous entry about Morts, Nick Malik left an interesting response. What caught my eye the most was his comment that:

"If you find yourself having to maintain a program that was not written to be maintained, don't blame the maker of the tools!"

I agree with this sentiment to a large degree. How people use the tools, is critical. But, that's only part of the story. See, a lot of tools don't lend themselves towards wiring maintainable code. Some of Microsoft's current tools fall in that category, unfortunately. For example, some don't lend themselves towards creating testable code. That's a big problem all by itself.

So I'd like to take Nick's comment and turn it an opportunity. Sure, it's the people using the tool that take most of the blame, however, the maker of the tool may (should!) have a significant responsibility in creating tools that encourage the creation of maintainable code. (Notice I use the word encourage here).

There's a thin, but significant line between tools that allow you to create crappy code quickly and then leave you high and dry, versus tools that encourage you towards creating good code. The key here is that the tools should make it as painless and natural as possible to do the right thing. This is not about wizards. It's not about visual designers. It's about code.

Microsoft is in a unique position to provide this, but so far some teams within it insist on making the default way of creating applications to be the one that favors quick and dirty over the one that favors maintainable code. The latter does not need to take longer, be more complicated, or be harder than the former, but some tools insist on making it that way. Choosing the right abstractions, by the way, is a key step here.

Microsoft, Morts

There are some discussions going on at this time on the community around the topic of
writing maintainable code and the different trade-offs a given "project reality"
might force on the developers involved in it. Very much worth reading and highly
recommended everyone reads and participates. Jeremy Miller beat me to it with some
good comments, as well.

My own personal opinion on the matter is a bit of a mixed bag (and so at times I might
seem to contradict myself).  On one hand, I find myself in total agreement with Ayende and Sam (just to name some of the most vocal proponents) that raising the level and knowledge of the developers that are going to be receiving the application is a critical step. I am a strong believer, learned from my own personal experience, that there's no amount of tooling and supervision/control that can "fix" the deficiencies of the team members themselves. It just simply doesn't cut it.

I believe says it best when he says that "Because my view is that having the developers learn a better way to build software is much less costly than continuing to produce software that is hard to maintain". I couldn't have said it better.

I am, however, sensitive to the dilemmas brought up by JDN and Frans Bouma, both of which have articulated their concerns and point of view in very provocative and thoughtful ways. I'm sensitive because I've found myself in their position a few times, and I've made the same choice they've argued in some of those occasions. However, my experience also shows that making that trade off, at those times I've made it, has eventually shown to have been a less than optimal decision.

Given this, I'm firmly in the camp that a) you should strive to avoid making that choice if at all possible, and b) you've got to be pragmatic about it. Sometimes, yes, organizational dynamics and politics play a role here, even if we disagree with it. So sometimes that might be the right choice to make, but rarely (if ever) for purely
technical reasons. And the whole "other developers might not get it" is, in the end, a red herring and tends to obscure the real reasons and motives behind it.

Why is it a red herring? Because it is usually a sign of the "we want to have a few highly skilled developers and lots of unskilled, cheap developers for the 'easy' stuff" mentality that pervades a lot of the companies in our profession, and it's just one I can't agree with. It's not that everyone should have 10 years of experience building extremely complex applications, but rather that everyone should have the opportunity to do their work to their best of their abilities. Inevitably, I find that this sort of mentality tends to set bounds that developers can't later cross easily without a lot of push back from management and the organization, leaving unskilled developers without a path they can collaborate with their more skilled, more experienced peers to grow their own skill set.

In many ways, this is a topic that strikes close to home for me, for several reasons. First of all, this kind of discussion is one of the reasons I decided to quit my last job and start my own company. In my point of view, the whole concept that the people are the key ingredient that make/break a project is absolute key. It's not about how much experience and knowledge the developers have. This is a significant component, for sure, but one that can be acquired with time. What is absolute key is the attitude: 

• A willingness to constantly learn and look for new opportunities for personal/team/product improvement. 
• A commitment to satisfying the client/costumer/user.
• A commitment to being ethical, honest and professional about your work and your own capabilities and limitations.
• Awareness of your context and that of your project/product.
• Caring about what your doing and being enthusiastic about it.
• Being critical about your own work and those of others, even if your believe others are above you or have different responsibilities (say, project manager or architect). Note this is not about constantly criticizing other people's work; it's about thinking critically about what the work that's being done by the team as a whole and the results.

I've seen many developers that lack one of this. Some are just 9-5 guys [1] that just want to get through the day without caring about the end result. Others have no desire for learning new things or getting out of their comfort zone. Others simply don't care about what other people do or what they do, usually manifested by them saying they're done implementing something and when you go look it doesn't even compile. Others will just do what their told to do and never even stop considering if it makes sense or if indeed it is the best way to do it.

Like Ayende, I refuse to be just a replaceable cog in a big machine; I want to make a difference and continuously learn and grow my skill set. I wouldn't have it any other way.

So it's about lots of different things. I love working with people that are critical about my work; they make me be a far better developer, and by listening to their opinions and sometimes different alternatives they propose I myself learn a lot. Sure, it's sometimes hard to listen to it all, but it's much worth it.

Arguing about the right things
I think one aspect that has tended to mud a bit the discussion is that we put a lot of different things into the same bag, which makes everything more confusing. For example, some people have mentioned MVP/MVC, ORM and TDD as important aspects in achieving maintainability, which some people have reacted a bit against.

From my point of view, the problem here is that we're mixing practices with tools. For example, TDD is a practice, and one that indeed is (imho) very important in facilitating the creation of maintainable code. But by itself it is no silver bullet (my friend Sam, for example, always talks about using the full set of 12 practices proposed by eXtreme Programming, not just TDD).

On the other hand, ORM and MVP/MVC are tools (yes, patterns are just design/coding tools, in the end), and sure, they can significantly help in producing maintainable code. But they are just tools, and you have to evaluate their impact and usefulness in each case. Some projects might simply not benefit from using ORM
(for example, this is rarely a useful component in the integration project's I've worked on), while it might reduce the amount of hand written code in your typical business application (and less code will always mean more maintainable code). But others might prefer for certain applications the use of code generation instead of an ORM and, you know what? That might be a perfectly valid choice in the context they're in. What's key here is
that they've done the analysis and choose what they believe it's best for them given their context.

Note: It's perfectly possible that the choice still turns out to have been the wrong one in the end, given that many times you start out with limited information from which to make your decision; but that's life.

It's about the future

One key issue I've seen again and again is that many developers don't even care about writing maintainable software, simply because they're not the ones that will have to maintain it. It's a very pervasive mentality in some circles that has been brought, in part, by the outsourcing of software development (something I make my living off, by the way). For example, in Colombia, a lot of companies have no internal software developers anymore, so external providers come in, create the initial release of an application and go away, many times never to see that code again except for one or two fixes during stabilization.

This means many developers don't really learn about the value of writing maintainable software because they it's easier to justify to yourself the writing of poor code when you think "I'm not going to maintain this later on, so why should I care?". This is not only a very egotistical point of view (and easy to fall on) but also ethically challenged. But what's worse is that it is a complete fallacy: you're still maintaining your code, and every day you write poor code in a project it's more code you have to maintain. It's just a lot of people seem to think otherwise and lie to themselves as a defense mechanism against the pain their going though every day on their project.

[1] there's a difference between wanting to have a life outside of work (good) and not giving a shit (bad).

Software Development, Maintainablity

My good friend Sam Gentile pointed to me Nick Malik's post on "Tools for Mort", in which Nick responds to some comments made by Sam a few days ago. I don't particularly agree with Nick's point of view. Several things bothered me about this post.

Why are we talking about Mort again?

First of all, I've said in the past that I don't particularly care in the Mort/Elvis/Einstein personas. Besides the fact that they tend to split users/developers around what I believe are the wrong areas, they are way too misinterpreted all around. Just bringing up the whole Mort topic is a sure way to turn a discussion in an unproductive direction.

What's worse, Nick apparently thinks Morts are the great Agile developers fighting the corporate world. Frankly, I have no clue where he got that idea from, but what do I know.

Look, it's great that there are people leveraging office and other platforms to solve business problems and get work done. There's a lot of really good use cases for that technology. However, it doesn't mean all software projects should be solved that way. In some scenarios, these kind of tools are great for solving immediate issues, but many times they are not suitable for building long-lasting, scalable solutions. Both sides of the software spectrum have different needs and deserve different solutions.

However, let's be clear about why the term Mort got a bad reputation: It was typically applied to people who didn't quite understand the tools/environment they were working on, creating half-assed applications that while did the trick initially, were a living hell to maintain because they didn't respect the most basic principles of good software development (in many cases, were not even aware they existed). Hey Nick, let's be honest here: your "Mort" friend was definitely no Mort if he was doing continuous integration and automated unit testing [1].

Sam doesn't get Agile?

Nick goes on to say:

"Do you really mean that Microsoft should make a priority of serving top-down project managers who believe in BDUF by including big modeling tools in Visual Studio, because the MDD people are more uber-geeky than most of us will ever be?  I hate to point this out, Sam, but Alpha Geeks are not the ones using TDD.  It's the Morts of the programming world.  Alpha geeks are using Domain Specific Languages."

From this sentence alone it's clear to me that Nick is obviously not aware of Sam's extensive and continuous efforts talking about "agile architects" and railing against BDFU. Really, you might want to look a bit around before making those kind of comments.

Now, Morts are the ones doing TDD? Wow. color me surprised. Alpha Geeks use DSLs? Really? AND THEY DO NOT DO TEST DRIVEN DEVELOPMENT? WOW.

Hummm...not quite. Most of the so called Morts have no freaking clue what Test Driven Development. People like the Code Better guys, Ayende and a lot others are precisely doing that: Trying to raise the level of awareness in the community about TDD/DDD and improving the way they write software. They are the ones trying to improve our field by making developers more aware of how they work and get them to write better software that not only works and solves the business problem it is intended to solve, but that is also maintainable. At least grant them that much.

I think Nick is also a bit confused about the whole Alpha Geek business. A lot of them do use dynamic languages and yes, a lot of them use them to create domain specific languages. But what makes you think they don't need TDD? Quite the contrary, Nick, they are far more reliant on TDD and automated unit testing.

Nick then says that "We [Microsoft] are the singlehanded leaders in the space of bringing BASIC developers up to modern computing languages.". Humm.... certainly true, you moved them over to VB.NET. It's certainly possible to write Object Oriented code in VB.NET. That, however, doesn't mean they are. Let's face it, there are millions of developers out there using VB.NET and (yes) C# that are still writing essentially procedural code (if they are lucky). Just because you declare classes doesn't mean you're doing OOD.

It's the tooling

But that's all mostly irrelevant to the discussion. I got the chance to speak about this with Sam and others during the past MVP summit, so I do think I have an idea what the fuzz is about (and because I happen to agree with the consensus). See, none of us are arguing that Microsoft has not done significant contributions to the community and even to the Software Developer profession, because they have.

What we do argue about is the tooling coming out of Microsoft and the way it is meant to be used. A lot of the software coming out of DevDiv these days seems to be very focused on building something quick. That's not a bad thing by itself, we all want software could be developed faster and that we could deliver it to the business as soon as possible.

What is a problem is that the tools enable that quick result at the expense of something else; something fundamentally important if you're not writing sample applications or "quick-n'-dirties". They are fundamentally non scalable (and I'm not talking about performance here), and unmaintainable if you just stick to the whole straight from the db databinding and drag and drop style of development Microsoft is so proud about. Better people than me have argued this more vehemently that I ever could so I'm not going to repeat it here.

I think that, at a fundamental level, there's a significant disconnect here. What some part of the community spends its efforts in is to try to raise the awareness, knowledge and capabilities of developers everywhere as a means. For them this is a key point in getting better software, with better and faster results. Instead of dumbing down the tools to suit the unwary developer, they are trying to smart up the developer to use the available tools more effectively.

[1] Somehow, I can't imagine Nick's Mort doing TDD while writing Excel macros, but maybe I'm just being cynic...

Microsoft, Agile, Morts

Last week (and Tuesday this week), my friend Carlos and I did a small BizTalk Server 2006 Clinic at one of our clients. I think it went pretty well overall. All the people that attended the clinic were very receptive and seemed really excited about the power of BizTalk and its capabilities.

I think one key aspect that helped a lot was that most of them already had experience in EAI projects, Web Services and XML/XSLT, and some of them had experience with their previous integration platform (TIBCO), so it was a lot easier to get things going in the right direction than when starting out with developers just getting into the integration space.

BizTalk Server

I've been spending most of my time this week back in the unmanaged world, writing C++ code again in good old Visual C++ 6.0. To make it even more fun, this was OLE DB with ATL. To be honest, took me a couple of hours to get the hang of it again, but after that my C++ started to come back more easily.

I did finally remember one of the reasons I moved off C++ to the managed code: Strings. Man, dealing with strings in C++ is just painful, even with CString, CComBSTR, _bstr_t, std:string and std:wstring at your disposal. Or maybe, that's just another reason it can be a pain in the neck. Anyway, if you find yourself writing OLE DB code again, the RowsetViewer tool in the MDAC SDK is a godsend .

One thing that I can say in favor of Visual C++ 6.0: The thing is freaking fast compared to Visual Studio 2005. However, I didn't remember there was no obvious way to change the font and font size, so using VC++ 6.0 on a hi-res screen isn't a particularly nice experience.

Visual Studio, Visual C++, ATL, OLE DB

... or not.

Visual Studio

Why does this always happen to me? I'm just now trying to install the Windows SDK (well, some updates, as I already had some of the basics installed), and the installer just keeps hanging during the "Component Detection" phase:

This is installing from a DVD, by the way, and not from the Web Setup, on a Windows Server 2003 R2 machine.

I'll try removing what I have already installed (mostly just tools + core sdk documentation) and try again. Meanwhile, anyone has any clues as to what the problem might be?

Update: This would be so much easier if the uninstaller didn't hang in the same spot :-(.

Windows SDK

In one of his articles on building a CAB-like infrastructure, Jeremy Miller brought out a pretty interesting point: The choice between using Events/Delegates and Direct Method Calls. This can be a controversial topic at hand, but it's an interesting aspect, and can significantly affect the readability of the code.

Events and delegates are very powerful features I use all the time. However, here's a tip: Be careful about building an entire framework or complex structure based purely around delegate calls. I've been spending a lot of time the past few days tracing, debugging and running through the code in the Base Adapter sample code in the BizTalk Server 2004 SDK [1], which is exactly a little framework for building BizTalk Adapters.

Now, the base adapter is OK, in that it does make it a bit faster to develop adapters by taking care of a lot of the boilerplate code necessary. However, a significant part of it is built out of classes that use a lot of delegates (not even proper events, unfortunately) to notify of significant events around each other; like for example that a batch was submitted to BizTalk or that a message needs to be suspended.

The unfortunate side effect of this is that tracing the base adapter code in source code form requires a lot of patience and a lot of Find References/Find Definition jumps all around to figure out exactly what's going on. In fact, I've spent quite a few hours on it and the code can be significantly convoluted; and parts of it are just a lot easier to trace using Step Though/Step Into in the debugger; which is rather frustrating.

So next time you want to build a framework or library and think gluing all together with delegates and events is cool; make sure you've got a real use case for them and that they are not going to end up hindering readability and maintainability.

[1] The version included in the BizTalk 2006 SDK is different and a lot simpler. I still don't quite like it and generally prefer to write directly against the Adapter Framework APIs, but that's just me.

BizTalk, Base Adapter, Delegates

Today my MSN Messenger icon went missing in action:

I've been playing lately with Cardspace and I really like the concept. Implementing Cardspace, server-side on a web site, is not all that hard. I started playing with this and using the TokenProcessor.cs code found in some of the Cardspace samples makes it fairly easy to get started. The code is ugly and somewhat poorly written, but it does the trick if you just want to get started in a hurry.

What I do not quite get is... why wasn't a basic token processor that you can use to implement Cardspace-based authentication on  a web application included as part of the Cardspace APIs in System.IdentityModel? Keep in mind, even the simple token processor included in the samples is well over 400 lines of code including the whole token decryption code.

So, any ideas? just why isn't this ohh so basic stuff already built into .NET 3.0?

Cardspace

I've been writing a simple (but important for me) Web Application these past few days using Monorail, and I will just say it totally rocks. Getting started with a monorail project, without using any wizard is actually pretty easy; I started by getting the most recent successful build. I was able to get the basic boilerplate code, even supporting localization, in very little time, and I've been very happy with just how simple and intuitive it is overall.

The only problem I had a bit was with documentation, as it seems to be a little older and doesn't quite match now. For example, the wiki entries for the Brail view engine (which I prefer over the nvelocity one) suggest templates and layouts should be named with a *.boo extension, when it should be *.brail.

Oh, and by the way, writing brail templates in Visual Studio sucks ... if you open the files using the HTML editor it works, but it is too helpful in reformatting the code, resulting in broken boo snippets.

Castle, Monorail, ASP.NET