What triggered this somewhat dramatic thought was that on my current project I’m gently persuading the other developers to move, as the project keeps growing, from a Transaction Script approach to a Domain Model approach. However, I’m not using these terms, and I’m hesitant about forcing the point. My colleagues are for the most part experienced programmers that know how to get a program production-ready, but who don’t necessarily spend time reading about design patterns. They call themselves developers and are somewhat distrustful towards anyone preferring terms like analyst, designer or engineer. Frankly: I’m worried to not fit in, to come across as that new guy with his far-fetched book ideas.

What’s helping my coming out is that I’m reading Agile Principles, Patterns, and Practices in C#. In particular, I like an idea that I found in the appendix, a reprint of Jack W. Reeves’s article What Is Software Design?. The result of any designing effort, he says, is a document, based on which then the rather mechanical act of building the product can start. Applying that to software development, he says:

After reviewing the software development life cycle as I understood it, I concluded that the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings.

As I said, I really like this idea, and it goes a long way in reconciling me with agile practices, what the rest of Martin’s book is about. You see, I’ve always felt instinctive distrust towards some aspects of agile programming, like the down-playing of documentation and upfront design in favor of producing working code fast. In fact, I felt that this way of working made software development feel less like a serious engineering discipline. After all, who would want their house built by an architect that says: “I’ve sketched out the main walls, the rest we’ll fill up as the brick-layers progress.”?

But if you start regarding anything upto and including the writing of source code as design, the perspective changes. It’s fine if there’s no definitive design before you start coding, because writing code is an integral part of the design effort. As long as you’re sure that the design is sound when the brick-layer/compiler starts his work, you’re fine.

I’m still somewhat suspicious about the whole concept of agile programming – in particular their view on social relations in developers teams seems somewhat utopian to me – but at least I feel like I’ll read the rest of the book with a more open mind.

There will even be a new type called dynamic. Variables of this type – and here it gets linguistically confusing – have no explicit type. In other words, the compiler can’t determine their type and check their use accordingly. It’s up to the runtime to find out what kind of beast the dynamic variable is really pointing to.

With this move, I guess that C# definitively gives up all hopes of ever winning an award for sparsity or elegance. The distinction between dynamically typed and statically typed languages has always been a rather radical one and a language not choosing one or the other feels like having two roofs on your house because the architect couldn’t make up his mind.

But well, C# has never pretended to be the most elegant or consistent language. Rather, it wants to be a multi-functional tool that supports different styles and lets you build a wide range of applications efficiently.

Still, I have my reservations about this novelty, mainly because C# is also a language that is used by programmers with very different degrees of knowledge/experience. I fully expect, at some point in the future, to be debugging codes where all variables are dynamic because that was the easiest way to get it all up and running. After all, that’s how GoTo got a bad rep.

“The Microsoft Sync Framework is a comprehensive synchronization platform that enables collaboration and offline scenarios for applications, services and devices. Developers can build sync ecosystems that integrate any application, any type of data, using any protocol over any network.”

With this framework Microsoft is obviously responding to two (connected) trends:

1) Users more and more use different devices (desktop, laptop, pda, smartphone…) to perform the same tasks and need to keep their data synchronized between all these pieces of hardware.

2) The growing market of so-called OCAs, or Occasionally Connected Applications. This refers to applications that use a server but are typically also used in situations where no network connection is available. This implies that (part of) the database needs to be “taken offline” (moved to the device that’s running the application) and that afterwards changes on that local copy need to be integrated and reconciled with the server database.

The framework should enable developers to respond more easily to these trends in their own applications by providing a standard synchronization model and libraries for typical tasks. Details can be found in the MS Documentation. In particular, most of the relevant classes are in the Microsoft.Synchronization namespace.

More links:
Download of the CTP2 release
Introduction to the Microsoft Sync Framework Runtime
Sync Services for File Systems
Tutorial – Microsoft Sync Framework Basics
SQL Express – Client Synchronization Sample

Well, you’re him, I’m afraid.

But don’t worry. Soon we’ll get this party started with some posts about the Microsoft Sync Framework, WCF, netTiers and/or any other goodies that we find on our yellow brick road through the land of Ozzie.