Hobbyists Speak for Themselves

Kathleen Dollard's recent Guest Opinion inspires reaction. Some hobbyists want Microsoft to continue support for VB6, while full-timers advise amateurs to step up to the .NET plate.

• By Readers of Visual Studio Magazine
• 06/01/2004

Letters to the Editor

Posted April 9, 2004

Letters to Visual Studio Magazine are welcome. Letters must include your name, address, and daytime phone number to be considered for publication. Letters might be edited for form, fit, and style. Please send them to Letters to the Editor, c/o Visual Studio Magazine, 2600 El Camino Real, Suite 300, San Mateo, CA 94403; fax them to 650-570-6307; or e-mail them to [email protected].

Hobbyists Speak for Themselves
I am writing regarding Kathleen Dollard's Guest Opinion, "Save the Hobbyist Programmer" [April 2004]. I am one of the "hobbyist programmers" that Kathleen speaks about. Although my title is "sales representative," my background, interests, and the needs of my customers allow me (or dictate, depending on how you look at it) to do some programming for about 10 percent or more of my time each week. I have used Visual Basic 3 through 6 and VBA, along with some VC++ and other languages, and I am currently still using VB6 for the vast majority of my projects.

I appreciate and understand at least some of the technical advantages of VB.NET, but I have yet to make the switch to that language because for the work that I do—creating utility applets that work with my company's data system for chemical analysis instrumentation—VB.NET's "improvements" don't appear to give me any additional tools that I require to do my work. While it might certainly be the case that VB.NET does in fact have something to offer someone in my position and I'm just unaware of it, I have yet to run into a problem that I could not solve using VB6. Plus, there is the matter of training myself, or receiving training, to use VB.NET when it is not an "official" part of my job.

I would argue that the "hobbyist programmer" doesn't really need anything from Microsoft aside from continued support for VB6. I believe the reason people such as me continue to use VB6 is not only because of the training hurdle, but because we can accomplish our tasks in VB6 and don't require the features of VB.NET. When things get sufficiently complicated, we either turn to other resources or move to a different programming platform. But we'd prefer to make that choice on our own, not have Microsoft make it for us.

Jim Edwards, Highlands Ranch, Colo.

Kathleen Dollard's Guest Opinion, "Save the Hobbyist Programmer," actually makes two points. First, she argues we need to ensure that our programming technologies and tools accommodate the "hobbyist" or part-time programmer. Second, she argues that the burden of ongoing training the professional developer carries in order to stay knowledgeable and productive has become too great. Her second point, with which I partially agree, helps refute her first point, and supports my argument that .NET, specifically VB.NET, need not and should not accommodate the "hobbyist" programmer any longer.

The rate of technological change programmers face today can only possibly be handled by a career full-timer. Software development today is a job for the fast, the bright, and the dedicated. It's a brutal meritocracy, the standard of merit being the quantity and quality of deployed and maintained applications one produces. Those who produce keep their jobs or their contracts, and those who don't get outsourced to Bangalore, or something like that. Slowing the rate of introduction of new features and functions into VS.NET for the sake of the "slow group" only jeopardizes our competitive position as .NET developers and our livelihood as professionals. There are too many competitive pressures for it to be otherwise: the growing trend of international outsourcing, with its resulting layoffs and adverse increases in the supply of available programming talent; platform competition with Java and Linux; corporate financial pressures and reorganizations; changes in business conditions; and so on.

These pressures and challenges demand our best efforts and full attention. Going forward, I can't imagine too many developers succeeding if they also have non-developer responsibilities. To paraphrase Ernest T. Bass, is you is or is you ain't, a developer. To compete, most developers will have to work beyond full time in order to get results today and train for tomorrow. In this post-bubble world, profit and productivity are paramount. There's no place for mediocre work, at least not in any business that has to compete.

But in order for the dedicated professional to succeed, she needs every productivity-enhancing tool Microsoft can give her. This is not the time for watered-down development tools. Ms. Dollard presents two archetypes to make her case that we should care about the part-time programmer. There's the Smart Knowledge Worker, whose job has evolved to include some programming, usually because the organization is small or the person in question is personally motivated to program but is unwilling or unable to give up his other business responsibilities. This is the person Ms. Dollard wants to "save" by keeping VB in such a state that the Smart Knowledge Worker can still use it with a minimal learning curve. Then there's the Geek, the programming child prodigy who never stopped. This is the person Ms. Dollard says we shouldn't cater to exclusively at the expense of the Smart Knowledge Worker. But there's a third type she left out, whom I'll call the Bootstrap Developer: the motivated career-changer who made a conscious decision to become a full-time professional developer, and who self-educated her way to expertise. There are many of these, more than most people realize. My point is, the population of professional full-time developers is large enough to warrant the full attention of the Visual Studio teams at Microsoft. And if we win the platform war, which I believe we will, that population will grow with the upsurge in demand for our skills. Some part-timers will become full-timers, and we'll welcome them to the guild. Some Java guys will switch over. We'll welcome them too, but put them at the back of the line. But we can win only if our developer tools not only keep up with the state of the art, but define the state of the art.

Have you ever seen the sort of business applications part-time programmers create? These apps end up being rewritten, by a professional. So, is the part-timer worth saving? Well, is the output of the part-timer worth saving? I'm suggesting that we can't afford the wasted effort. We can't afford the opportunity costs. We sure as heck can't afford giving the competition an opportunity to label VB.NET as "not for the serious developer."

So where does the current part-time programmer fit into the future? Ms. Dollard states we need those with domain knowledge and business experience as much as ever. There are roles for them that can't be shipped to India or anywhere else. I'm thinking of the business analyst, the product manager, the key user, the beta tester, the requirements gatherer. If you're smart, you praise these people as much as possible, for they are vital to the project. Just keep them the heck away from the IDE. You don't have time to rewrite or maintain messy, ill-conceived code.

The part-timer is not the canary to us coal miners. That metaphor doesn't fly. We have more accurate indications of our well-being than whether the part-time programmer down the hall can do productive work any longer. A much more significant litmus test is whether Microsoft is releasing well-designed tools and technologies that make us more productive and encourage good software design (such as Whidbey and .NET itself), as opposed to tools rushed to the market just to fill a space.

Ms. Dollard is evidently a dedicated and experienced professional—exactly the kind of professional whom Microsoft, Visual Studio Magazine, and other content providers should consider their target customer.

Michael Caldwell, Burlington, N.C.

First off, thanks to Kathleen Dollard for sticking up for the little guy. I don't hold a computer-science degree, I just love computers and computing. I guess I'm your canary, just a hobbyist programmer who learned VB6 from a class or two while in college. When .NET came out, I knew just enough to realize how revolutionary it was. My head was slowly wrapping around the fact that (almost) everything was becoming not only possible, but easy for a stubborn person of my abilities to use. So I got stubborn.

And that's OK. I had to learn new things, because .NET was the new way to do things. And I grew as a programmer. Ultimately, we are all self-taught. The case can be made that RAD tools make development too easy. The climb up the learning curve causes one to, well, learn, and making that curve less steep might not save the hobbyist programmer after all, but deprive him or her. Complex things are complex.

I don't want to sacrifice usefulness for the sake of usability. I don't want my possibilities to be limited because it would take too long to have those possibilities explained to me. Ms. Dollard assumes that the hobbyist has a certain number of weekly hours to put toward his or her craft, and that devotion of time is what defines a hobbyist. Hobbyist programmers don't divide their lives up that way. Moreover, hobbyist programmers are every bit as able, if not more so, to take drastic changes in stride. Hobbyist programmers do it for the love. And they train themselves for the same reason. If Microsoft wants to make things more complex, I say bring it on. And hopefully, the canary will continue to sing.

Burton Johnson, Tucson, Ariz.

Stored Procedures vs. Parameterized Queries
Dan Fergus oversells stored procedures just a bit in "Speed Up Your ASP.NET Pages" [April 2004]. I believe stored procedures are often a good thing, but they are not, in and of themselves, the solution for script attacks. The real solution is parameterized queries, with or without stored procedures. Even if you cannot use stored procedures, you can prevent SQL Script injection using parameters.

Douglas Reilly, Brick, N.J.

I'm not sure I oversold stored procedures. If anything, I should have spent more time discussing the benefits, but it was an article about performance. Sure, you can use parameterized queries outside of stored procedures to protect against script attacks, but there are other benefits to stored procedures. One point I didn't make in the article was that you can protect your database in the case where your connection string is ever compromised. If the user specified in the connect string only has permission to access the database through stored procedures, then he cannot do bad things such as dropping tables. That's just one more reason why stored procedures are beneficial beyond script attack prevention. —D.F.