Panopea Consulting - iMIS Blog

Join NiUG or ...

...lose your access to the list serve. Starting November 1, the NiUG list serve will be a members-only benefit. NiUG is a great group and is only $100/year for organizations using iMIS.

Don't get hyped by the hype

From the Developer Update newsletter of SQL Magazine:

WWMD--What Would Microsoft Do?

By Scott Swigart, [email protected]

When the .NET Framework first shipped, many customers asked what to make of it. Was Microsoft expecting us to rewrite all its existing applications to run on the .NET Framework? My advice at the time was, "Let's watch and see what Microsoft does with its own apps."

Six years later, my advice hasn't changed, and Microsoft itself has provided us with a massive case study for how to integrate the .NET Framework into your development. Microsoft uses the .NET Framework extensively. For example, the Microsoft Dynamics CRM product was rewritten as managed code. Managed code is integrated deeply into SQL Server. Microsoft uses ASP.NET for large swaths of its Web presence. And, many Microsoft internal line-of-business applications have been rewritten in .NET.

In other words, when it's been time to rewrite a product or perform significant new development, Microsoft has opted to do much of that development in managed code. The picture is radically different with existing, successful applications, and the primary case in point is Microsoft Office. Despite the fact that the .NET Framework has been in the field for six years, Office hasn't been rewritten. As far as I know, there are no plans to ever rewrite Office as managed code. Instead, Microsoft is taking this existing mission-critical product with its large code base and extending it with .NET. It's quite likely that if you have a mission-critical product that's gone through a number of revisions, the smart strategy is to extend it with .NET, too, but don't feel that you're doing something wrong if you keep the bulk of the application as unmanaged code. Even Visual Studio is a hybrid managed/unmanaged application. Efforts to make the Windows OS contain significant amounts of managed code (a.k.a. Longhorn) ultimately failed, and Microsoft will release Vista with much of its functionality available as unmanaged APIs.

Speaking of Vista, that product will release with the hype machine volume cranked up to 11. Microsoft will be touting all of its developer features and screaming at you to leverage Vista-only features in your applications. Hmm.

What Would Microsoft Do? My advice remains unchanged. Let's see when Microsoft applications start using Vista features. Let's see when there's a Microsoft application that won't install on anything less than Vista. Heck, a lot of existing Microsoft products won't even run on Vista. My guess is that it will be quite some time before Microsoft ships products that require Vista, and despite the hype machine, I think that waiting to see how Microsoft applications use Vista is good advice for all of us.

SQL Server Security

Here are some basics on what you should be thinking about to keep your SQL Server secure and working well:

• Tricks that hackers use to gain access to your SQL Server
• Looking for malware on your SQL Server that may be compromising your security or hurting your server's performance
• Preventing SQL injections by hardening your code

Filling a Green Field

Wow, time flies. Haven't time to write anything here but I saw this article today and think it is a good one from the Developer Update newsletter from SQL Magazine:

Filling a Green Field
   by Bill Sheldon, [email protected]

   Developers commonly make the following two statements:
  - "If we could rewrite that application from scratch, it would solve most
of the application's existing problems and it wouldn't take anymore effort
than trying to update the current code to resolve the existing problems."
  - "The next release of '____' from Microsoft is bound to be unstable until
at least the first service pack because of all the bugs that will be
introduced."
   The first statement is known as having a "Green Field." The idea is that
when you start from scratch, it's like constructing a building on an empty
lot as opposed to renovating an existing building. This term is often heard
in relation to rewriting COM code to .NET code. However, in response to my
last column ".NET Now Positioned to Replace COM"
( http://lists.sqlmag.com/t?ctl=3B45F:7B47A ), a reader
informed me, in no uncertain terms, that, "The people in the industry that
tended to be disgruntled were the ones that couldn't see the wisdom in
rewriting code to be 32 bit from the ground up." However, the Green Field
comes with its own risks--risks that have been well illustrated in computer
history.
   For those of you unfamiliar with that history, let's use a simple example.
Initially, Netscape was the browser leader. It then decided to rewrite its
entire browser from the ground up. This was right around the end of the
transition from 16-bit to 32-bit OSs, and part of the plan was to remove all
the legacy code in the next version of the browser. To make a long story
short, Netscape 5.0 never shipped, and by the time Netscape 6.0 shipped, its
market leadership was a thing of the past. Don't get me wrong--the browser
still exists. But let's be honest: How many of you have tried Netscape 8.0?
   This brings us to the second statement I made in regard to Microsoft
software and bugs. Now, you might not like Microsoft and you might complain
about its software, but you should be willing to learn lessons at Microsoft's
expense. First, let's recognize what the market illustrates. Microsoft knows
how to ship software and knows how to create good software. Yet even
Microsoft introduces bugs and omits needed features when it releases new
software. What makes you think your organization will do any better?
   I bring this up because the most popular statement from application
developers is, "Let's rewrite it from scratch." The idea that we can do it
better if we just start over has been proven not be true time and again.
Don't get me wrong--there are situations in which you might have to throw
away an application for business and technical reasons. However, attempting
to rewrite an application (as opposed to rewriting a feature in it) from
scratch just because you think you could do it better is almost always a bad
idea.
    In terms of the developer's day, updating software is harder than trying
to write software from scratch. But you should remember that although old
code often looks ugly, it has one key advantage: It runs. The old code has
been debugged and, in many cases, has obscure patches for unexpected
scenarios that you'll spend weeks figuring out again. Rewriting code from
scratch is something you should do only in rare cases. Take the approach that
today's green field is tomorrow's green swamp. A complete rewrite might seem
easier, but history shows that it's a mistake. Think about this: Why did
Microsoft build in several tools to help with migration to .NET? Because they
thought everyone understood the danger of rewriting applications from
scratch.
   Finally, as an example of the potential pain of migration, consider that
Microsoft needs to get Visual Studio 2005 working on Vista, a 64-bit
compatible OS. I want to be clear--the challenges aren't with .NET
applications, but with the application Visual Studio 2005. Given what S.
Somasegar writes in his blog "Visual Studio 2005 SP1 Beta and Visual Studio
support for Vista" ( http://lists.sqlmag.com/t?ctl=3B45B:7B47A ),
Microsoft isn't finding it easy to get its developer tools running on this
new platform.

[emphasis mine]