Microsoft's SOA vision: 'The model is the application' Tuesday, October 30, 2007

TechTarget’s SOASearch.com reported today that Microsoft is at it again, selling more snake oil which promises to cure all your application development impediments – again. The approach is called 'The model is the application' and the idea is that business users and developers should collaborate their way to a functional software system using post-Orcas releases of the .NET Framework, Visual Studio.NET, and BizTalk Server.

According to Burley Kawasaki, director of Microsoft's connected systems division, they are building “a general purpose set of modeling tools, modeling language and repository that can bridge all the various types of models that describe an application and move models to the center of application development” and that “[Microsoft] has figured out a way to deliver on the promise of model-driven development in SOA.” In Microsoft's vision, “business users, SOA architects and developers will be able to use the modeling tools in the next version of Visual Studio to collaborate on composite applications.”

I am of the opinion that all the whiz-bang designers or code generators never work as promised and are not as cost effective as the marketing hype leads one to believe. I get the shakes when "composite anything" is mentioned in reference to software development (think: Composite UI Application Block). Discounting the role of good software engineers, software architects, and product owners (a.k.a. business analysts, product managers, etc.) is a big mistake. I am also of the opinion and have proven in my experience that when waterfall practices (which was mentioned in the article briefly) are replaced by solid Agile, XP, TDD, and DDD practices, this ensures a higher chance of software project success – something no designer tool can deliver.

This story reminds me of a piece done by Alex Papadimoulis discussing the promises by a web start-up company called Coghead touting something in the “easy software development – we promise” space where he says that “perpetuating the myth that programmers are an unnecessary part of the software development process does nothing but alienate users and frustrate them when the (programmer-developed) ÜberTool fails to deliver the results it promised.”

I will be filing both offerings (Microsoft and Coghead) under the same conclusion: “I'll believe it when I see it.”

[updated]

NDatabase 6.0 Announced Sunday, October 14, 2007

NDatabase is a façade library which provides a simplified interface to complex data access related bodies of code such as ADO.NET and NHibernate. It is open source and I am the coordinator. I am pleased to announce that the 6.0.0.x release has been underway for some time and will be released in the near future. Major enhancements include:

• ADO unit of work scope.
• NHibernate unit of work scope.
• WCF service method UoW behavior.
• Reorganized solution/namespace structure.
• Rework of the IOrmNetDatabase interface.
• And more...

This release will cause breaking changes from previous versions, but I feel it is warranted to better meet the project goals. A firm release date has yet to be pinned down, but it will be before years end.

Project site;
http://www.codeplex.com/NDatabase

You need an AgileFaçade™ Tuesday, October 9, 2007

I recently coined the phrase “You need an AgileFaçade” when I was discussing project/process management choices with a colleague. When you are forced to use waterfall approaches for project/process management, then you could use the façade pattern in real life to create an Agile buffer around the waterfall demon. It was sort of a tongue-in-cheek dialog; but is it really that farfetched…? Just because everyone else is thinking of the project in waterfall terms does not mean your thought process cannot be Agile-centric…

C# Compiler and Infinite Iterating Methods Friday, October 5, 2007

A friend of mine (and fellow C# coder) asked me to consider the following code:

public int ExampleMethodA()
{
    while(true)
    {
    }
}

public int ExampleMethodB()
{
    const bool loop = true;

    while (loop)
    {
    }
}

public int ExampleMethodC()
{
    bool loop = true;

    while (loop)
    {
    }

    return 0;
}

He thought it was odd that the C# compiler (.NET Framework 3.0) willingly compiles example methods A and B, but complains (as expected) on method C until you explicitly return a value.

I presented a theory that the C# compiler must optimize away the need for the return statements in example methods A and B, but not C. To dive deeper and prove my hypothesis, I dusted off trusty old ILDASM.exe and examined the MSIL generated in all three cases.

.method public hidebysig instance int32  ExampleMethodA() cil managed
{
    // Code size       9 (0x9)
    .maxstack  1
    .locals init ([0] int32 CS$1$0000,
           [1] bool CS$4$0001)
    IL_0000:  nop
    IL_0001:  br.s       IL_0005
    IL_0003:  nop
    IL_0004:  nop
    IL_0005:  ldc.i4.1
    IL_0006:  stloc.1
    IL_0007:  br.s       IL_0003
} // end of method Program::ExampleMethodA


.method public hidebysig instance int32  ExampleMethodB() cil managed
{
    // Code size       9 (0x9)
    .maxstack  1
    .locals init ([0] int32 CS$1$0000,
           [1] bool CS$4$0001)
    IL_0000:  nop
    IL_0001:  br.s       IL_0005
    IL_0003:  nop
    IL_0004:  nop
    IL_0005:  ldc.i4.1
    IL_0006:  stloc.1
    IL_0007:  br.s       IL_0003
} // end of method Program::ExampleMethodB


.method public hidebysig instance int32  ExampleMethodC() cil managed
{
    // Code size       18 (0x12)
    .maxstack  1
    .locals init ([0] bool loop,
           [1] int32 CS$1$0000,
           [2] bool CS$4$0001)
    IL_0000:  nop
    IL_0001:  ldc.i4.1
    IL_0002:  stloc.0
    IL_0003:  br.s       IL_0007
    IL_0005:  nop
    IL_0006:  nop
    IL_0007:  ldloc.0
    IL_0008:  stloc.2
    IL_0009:  ldloc.2
    IL_000a:  brtrue.s   IL_0005
    IL_000c:  ldc.i4.0
    IL_000d:  stloc.1
    IL_000e:  br.s       IL_0010
    IL_0010:  ldloc.1
    IL_0011:  ret
} // end of method Program::ExampleMethodC

Interestingly enough, example methods A and B emit the same MSIL, and they have no RET instruction. On the other hand, example method C has slightly differing MSIL, due to a non-constant looping condition and it does have a RET instruction.

Theory confirmed: the C# compiler optimizes away the need for return statements if it can be determined the method will never actually return.

First Post Thursday, October 4, 2007

Finally, after years of avoiding it, I have decided to try blogging...

About the Blog Title:

"Software is Hardwork" is a play on words; "hardwork" does not mean "hard work", but rather "hard" as opposed to "soft" - as in hardware and software.

Disclaimer: The opinions expressed here on my personal blog no way represent the opinions of any other person, group, company, or other entity. There is no warranty to accuracy or fitness for any purpose.