From the Editors: Don't fracture .NET
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By SD Times News Team
September 1, 2008 —
We are glad to hear that Microsoft is concerned about the rampant proliferation of its .NET frameworks and libraries. We’re even more pleased that Microsoft is taking steps to address it—even if that is changing how the company creates its software.
The original .NET framework was a relatively small, clean, consistent and approachable framework. Since then, Microsoft has been aggressive in expanding .NET, making it more attractive to enterprise consultants and developers.
In the process, developers have grown increasingly frustrated keeping up with the pace of change, particularly as recent versions of the framework appear to indicate forks in the road, instead of evolutionary developments. For example, .NET 3.0 and 3.5, which still run on top of the .NET 2.0 runtime, introduced confusion as to which version has what, where and why.
In documents reviewed by SD Times, Microsoft acknowledged that there was a lack of coordination of concepts among technologies in those releases. That’s an understatement. The introduction of the ASP.NET Model-View-Controller code—a splinter framework—compounds the problem, even though it has been well received by the developer community.
Indeed, the Microsoft groups that are contributing to the .NET framework are making excellent contributions, but too many cooks spoil the broth. Microsoft regional director Billy Hollis’ remarks about the root cause of the fragmentation were harsh, but spot on: Microsoft’s aggressive culture values shipping software above all else, and that’s a problem.
.NET has changed how developers code, including Microsoft’s own product teams, and .NET may be a victim of its own success. Development has become more rapid, and coordination and oversight have not kept up with the rapid pace of .NET’s evolution.
Hollis’ suggestion that a cultural shakeup is necessary is a friendly warning shot over Microsoft’s bow. The company needs to change how it is developing .NET. Without restoring sufficient coordination, Microsoft risks introducing more accidental complexity.
There are some indications that Microsoft is taking action. The Silverlight and .NET 3.5 client profiles are smaller, more approachable iterations of .NET.
Prescribing that Microsoft change how it develops software is a radical suggestion, and certainly it would be a difficult transition. There is precedent, however: open source. The company should take cues from the open-source community’s approach to creating software and emphasize evolutionary rather than revolutionary releases.
That is easier said than done, but a decisive move must be made before the fate that befell ActiveX, MFC, a multitude of OLE libraries, Visual Basic and Win32 pulls down .NET. Indeed, Microsoft’s track record on managing fragmentation in its frameworks is not encouraging.
.NET provided Microsoft with a beautiful opportunity for a reset. As the Beatles said in their song “Revolution,” “You ask me for a contribution. Well, you know. We’re doing what we can.”
Win64’s time is finally here
If you purchased a Windows desktop computer in the past few years, chances are the machine was running a 32-bit operating system on top of a 64-bit Intel or AMD processor. Unless you specifically requested a 64-bit version of Windows XP or Windows Vista, most retailers and manufacturers pre-installed the 32-bit OS.
For most consumers and business users, that was just fine. The 64-bit versions of Windows introduced additional complexity, like such dual registries, and had the potential for drivers and application compatibilities. This was offset by … nearly nothing. Unless applications were written to exploit the 64-bit processor’s extra registers and other optimizations, you’d only see benefits on desktop systems with more than 4GB of RAM. Only a few programmers, designers and gamers, until recently, had such systems.
That’s clearly changing: Finally, shipments of 64-bit Windows are beginning in earnest and may actually be outpacing those of 32-bit Windows.
It’s time for every Windows developer to prepare for the era of the pervasive 64-bit Windows desktop. It’s not a tidal wave, but it’s coming fast.
Related Search Term(s): .NET, Windows, Microsoft
Share this link: http://www.sdtimes.com/link/32788