DNA, SOA, Software Architecture, VB.NET, CMMI, Agile Development - Doing what Microsoft does, not what they say to do…
We are in a new era of trying to figure out what Microsoft is doing. To do what they say to do can lead to trouble. The past has proven this.
I learned this lesson years ago when MS was preaching the DNA model for building applications. Microsoft never implemented DNA in their own applications they always used ISAPI filters written in C++. The reason for selling DNA is that it was what the development community was capable of handling. Visual Basic was what their developers used so they had to make that tool available. Microsoft ignored the internet when companies like Allaire were building for the internet. Microsoft basically took all their non internet ready applications and tied them together with ASP glue and said we are internet ready and our solution for you is DNA. Microsoft has final gotten around to adding ColdFusion tags to ASP.NET 2.0, that ColdFusion offered 6 years ago.
DNA and ASP has been attributed with building a lot of successful applications, but those applications for the most part are a conglomerate of spaghetti code and are maintenance nightmares. Back in the days of ASP 2.0 I always tried to sell my clients on ColdFusion, but they would usually never bite because of the upfront cost. I couldn't convince then that going with ASP and VB COM+ DNA would cost them much more in the long run because of it not being maintainable or modifiable. But they all did learn the hard way, and my predictions we never disproved.
Where we are now is in the middle of a landslide of Microsoft suggestions on how we should approach development with their tools and trying to discern which are valid approaches to development, which tools should be used, and which are marketing propaganda to keep the development community happy and in their corner.
Microsoft is not in the same boat as they were back in the ASP COM+ DNA days. But we are still finding some things coming out of their camp that are market driven instead of best practice driven. Some examples of this are there approach to VB.NET, MSF for CMMI, MSF for Agile development, and their current Mobile development improvements.
Microsoft pushed the VB 6.0 developer to move to VB.NET. It took me 6 months on a state project to convince them they should not be developing framework components with VB.NET. After a few iterations of development they felt the pain I pointed out that would come, and we switched to C#. The first move of a new CIO at a company I worked for that developed hospital software was to change all development to C#. That meant changing 14 different development sites world wide. He gave everyone 6 weeks to get up to speed. No one had to leave because they couldn’t pick it up.
I am a firm believer that all Enterprise level applications should be developed in C# and if needed C++. VB.NET is great for Rapid Application Development of front end applications. C# is geared to be a RAD code level development tool, where as VB.NET is geared to be a designer RAD development tool. VB.NET also enables the VB 6.0 developer to continue to develop in a non-OOP fashion by using extra VB namespaces provided by Microsoft that wrap other .NET namespaces. This allows for some very dangerous developing to take place when it comes to performance and coding best practices.
Microsoft of course says the languages are equal, but that was a marketing ploy to not loss their VB community of developers. Culturally however, in the architect and developer community, a framework coded in VB.NET such as we are trying to implement is not viewed as being very credible. I have seen more VB 6 developers develop unusable code in VB.NET, than I have seen successful development since .NET has come out.
In truth I would be quicker to hire a 5 year veteran of Java to code C# than I would be to hire a 10 year VB veteran to code VB.NET or C#. Java developers understand OOP, VB guys have been fooled into thinking that they understand it.
One important thing to consider is the fact that Microsoft uses C# to develop it's products. BizTalk is a perfect example. The new tools in BizTalk 2004 has been developed in C# by Microsoft. There is an excellent article in SD Times on C# this month called 'One Language to Rule them All: C#'. It is not available on line yet but soon will be.
Microsoft has been preaching MSF for years. Their latest incarnations are MSF for CMMI and MSF for Agile development. Putting together processes that you use is one thing, but is Microsoft using these processes? If so, to develop what? And what level of CMMI have they been certified for? I will be steering clear of these process implementations until that is revealed.
For more on my thoughts on Process see these blogs:
The Process Ladder- UP, RUP, EUP, PLE, & Never Neverland
VSTS 2005, DSL, and Software Architecture
It is going to be hard to decipher what MS is doing in house with their tools at this point in time because they are already ignoring this release of tools and are head full bore into their next release of tools to support Vista and WCF. I found this out the hard way when I starting looking for support on Mobile 5.0 for the WS-* specs. Here was some of that process:
No WS-* support forces the use of SSL
.NET Compact Framework 2.0 Guidance and Documentation is Pitiful
WSE 3.0 cannot be used with the Compact Framework 2.0 on Mobile 5.0 devices
In the end it seems we are stuck with whatever was released in the first release of .NET CF 2.0 and are now on hold waiting for their next platform.
Trying to weed through all the marketing driven releases from MS is not an easy task, but in the end it is something that always needs to be done. I will be waiting to use DSLs and Software Factories until I see the first product released from Microsoft that has fully used Software Factories to develop it. I have a feeling I will be waiting a while. And I am really not interested in seeing a Software Factory that implements Pet Shop. Until Microsoft is selling pets, Pet Shop is just another marketing tool.
I learned this lesson years ago when MS was preaching the DNA model for building applications. Microsoft never implemented DNA in their own applications they always used ISAPI filters written in C++. The reason for selling DNA is that it was what the development community was capable of handling. Visual Basic was what their developers used so they had to make that tool available. Microsoft ignored the internet when companies like Allaire were building for the internet. Microsoft basically took all their non internet ready applications and tied them together with ASP glue and said we are internet ready and our solution for you is DNA. Microsoft has final gotten around to adding ColdFusion tags to ASP.NET 2.0, that ColdFusion offered 6 years ago.
DNA and ASP has been attributed with building a lot of successful applications, but those applications for the most part are a conglomerate of spaghetti code and are maintenance nightmares. Back in the days of ASP 2.0 I always tried to sell my clients on ColdFusion, but they would usually never bite because of the upfront cost. I couldn't convince then that going with ASP and VB COM+ DNA would cost them much more in the long run because of it not being maintainable or modifiable. But they all did learn the hard way, and my predictions we never disproved.
Where we are now is in the middle of a landslide of Microsoft suggestions on how we should approach development with their tools and trying to discern which are valid approaches to development, which tools should be used, and which are marketing propaganda to keep the development community happy and in their corner.
Microsoft is not in the same boat as they were back in the ASP COM+ DNA days. But we are still finding some things coming out of their camp that are market driven instead of best practice driven. Some examples of this are there approach to VB.NET, MSF for CMMI, MSF for Agile development, and their current Mobile development improvements.
Microsoft pushed the VB 6.0 developer to move to VB.NET. It took me 6 months on a state project to convince them they should not be developing framework components with VB.NET. After a few iterations of development they felt the pain I pointed out that would come, and we switched to C#. The first move of a new CIO at a company I worked for that developed hospital software was to change all development to C#. That meant changing 14 different development sites world wide. He gave everyone 6 weeks to get up to speed. No one had to leave because they couldn’t pick it up.
I am a firm believer that all Enterprise level applications should be developed in C# and if needed C++. VB.NET is great for Rapid Application Development of front end applications. C# is geared to be a RAD code level development tool, where as VB.NET is geared to be a designer RAD development tool. VB.NET also enables the VB 6.0 developer to continue to develop in a non-OOP fashion by using extra VB namespaces provided by Microsoft that wrap other .NET namespaces. This allows for some very dangerous developing to take place when it comes to performance and coding best practices.
Microsoft of course says the languages are equal, but that was a marketing ploy to not loss their VB community of developers. Culturally however, in the architect and developer community, a framework coded in VB.NET such as we are trying to implement is not viewed as being very credible. I have seen more VB 6 developers develop unusable code in VB.NET, than I have seen successful development since .NET has come out.
In truth I would be quicker to hire a 5 year veteran of Java to code C# than I would be to hire a 10 year VB veteran to code VB.NET or C#. Java developers understand OOP, VB guys have been fooled into thinking that they understand it.
One important thing to consider is the fact that Microsoft uses C# to develop it's products. BizTalk is a perfect example. The new tools in BizTalk 2004 has been developed in C# by Microsoft. There is an excellent article in SD Times on C# this month called 'One Language to Rule them All: C#'. It is not available on line yet but soon will be.
Microsoft has been preaching MSF for years. Their latest incarnations are MSF for CMMI and MSF for Agile development. Putting together processes that you use is one thing, but is Microsoft using these processes? If so, to develop what? And what level of CMMI have they been certified for? I will be steering clear of these process implementations until that is revealed.
For more on my thoughts on Process see these blogs:
The Process Ladder- UP, RUP, EUP, PLE, & Never Neverland
VSTS 2005, DSL, and Software Architecture
It is going to be hard to decipher what MS is doing in house with their tools at this point in time because they are already ignoring this release of tools and are head full bore into their next release of tools to support Vista and WCF. I found this out the hard way when I starting looking for support on Mobile 5.0 for the WS-* specs. Here was some of that process:
No WS-* support forces the use of SSL
.NET Compact Framework 2.0 Guidance and Documentation is Pitiful
WSE 3.0 cannot be used with the Compact Framework 2.0 on Mobile 5.0 devices
In the end it seems we are stuck with whatever was released in the first release of .NET CF 2.0 and are now on hold waiting for their next platform.
Trying to weed through all the marketing driven releases from MS is not an easy task, but in the end it is something that always needs to be done. I will be waiting to use DSLs and Software Factories until I see the first product released from Microsoft that has fully used Software Factories to develop it. I have a feeling I will be waiting a while. And I am really not interested in seeing a Software Factory that implements Pet Shop. Until Microsoft is selling pets, Pet Shop is just another marketing tool.
posted by tadanderson at 8:59 AM
0 Comments:
Post a Comment
<< Home