October 28, 2005 • Vol.27 Issue 43
Page(s) 23 in print issue
This week I gave a couple of sessions and a day-long ADO.NET workshop at VSLive in Orlando. These trips give me a chance to get away from the office and out into the real world. I find it essential to hear about the problems faced by developers working with the old, the new, the borrowed, and the blown technologies. Along the way I eat and visit with as many different groups of people as possible, as well as network with the other speakers. We trade stories and solutions and try to get a better understanding of what we should be telling our customers.
A number of common threads seem to tie these anecdotal cases together: Systems evolve over time and are often sewn together with spit, bailing wire, and COM. When companies combine, they inherit the applications and staff from their new partner. It’s like marrying a woman with a collection of Duncan Fife heirlooms; you have to figure out how to get her furniture to blend into your 1970s chrome and steel motif. Sometimes it might seem easier to find another wife.
Striking A Balance Between New & Trusted Code
Even when you work with your own company's applications that have developed over time, you're faced with the problem of getting new systems to interact with existing ones. It's a never-ending process. As each new fangled “universal solution” arrives, you have to balance the reality of your budget with the demands of the new features your staff and customers demand. Should you launch off and try this new technology? Many technical managers say the people they are trying to educate see the .NET tools and languages the same way a toddler sees a flash of metal in the sand. It’s new, shiny, and fun, and the first thing they try to do with it is stuff it into their mouth. The managers know from experience that these sparkly objects might be land mines. What’s bright and new is often untried, inexperienced, and unable to solve the problems.
We mentors and IT development managers have to figure out which of the new tools and interfaces can really help solve our problems. We need to ask: Should we try to create a single block of code that works to replace the existing code across all of the existing systems, or do we try to link these disparate systems together? Does it really make sense to have a single block of source be all things to all systems, or should we build a cohesive (albeit custom) set of code that deals with the specific reality of the platform?
Focus On What Matters Most To Developers
Every company I’ve worked with over the years has tried to leverage its investment in hardware, software, and (most importantly) skills to solve these problems. At the last SDR, I encouraged Microsoft to stabilize the development tools. In order for management or mentors to understand what works best, we all must get and stay up to speed on what the vendors (like Microsoft) have to offer and what experts and users (the consumers) outside Microsoft have to say about it.
Based on the increased number of Microsoft folks speaking at conferences nowadays, I suspect that Microsoft is worried that the message being given to developers and their managers by third-party speakers is not on target. Case in point: The VSLive conference devoted an entire hour to MARS (Multiple Active Result Sets), and they plan to repeat this session several times in upcoming conferences.
Microsoft encouraged these topics and provided the speakers, but it seems strange to me that it would want to waste time on it. MARS has many unresolved issues; I would have expected Microsoft to spend more time on the important issues that impact more developers. One of the most common problems deals with how ADO.NET 1.0 and 1.1 mismanage the connection pool. Version 2.0 fixes most of these problems, but none of the Microsoft speakers I heard discussed the new connection pooling work incorporated in the 2.0 Framework.
Very few applications failed or could not be written because MARS was not available, but thousands of developers find that their connection pool overflows during production. Microsoft worked hard to fix these pooling issues, but I guess bug fixes don’t have the same marketing appeal as MARS. After all, Oracle has had it for years; SQL Server did not. Microsoft needs to stop worrying about shapes for its .NET taillights and start figuring out what makes the cruise control disable the brakes at 85mph.