Don't Neglect Your Skills
A reader explains that job market forces often force developers to opt for the latest and greatest, rather than tried and tested; another reader explains why he voted for no products in the most recent Readers Choice Awards survey.
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].
Careers Drive New Technology Use
Kudos to Rockford Lhotka for his article about the goals of software developers often being at odds with the needs of their customers [Guest Opinion, "Software is Too Darn Hard," VSM April 2006].
It's true that what we do can be boring, day after day, month after month. The basic needs of your customers don't really change too much over time, and data entry and management applications still form a core part of what many of us do as developers. New technologies and ways of doing things can often spice up what otherwise might start to feel like drudgery, so I think we hedge a bit. We convince ourselves that this new way of doing something will be better for our customers, when really it is about us wanting to build a different kind of mousetrap.
But let's look at this from another angle. Yes, we sometimes over-engineer some solutions or develop solutions in new technologies when the old technologies would work just as well or, in some cases, even better for a given solution. Going with a current or previous generation technology might mean a better solution for your customers, but it can also mean career stagnation. We might want to use the latest and greatest technologies to implement solutions, but many potential employers expect us to be merely conversant in these technologies, yet also have some experience using them. Or, our own company might let us go in favor of other developers in the organization who developed with the latest and greatest technologies. Another all too common scenario: Continue to provide customers solutions with existing technologies—perfectly appropriate technologies—and yours is the kind of job that might be susceptible to offshoring.
It's a Catch-22: Develop with your customers in mind exclusively, and you might be arranging it so you don't really have customers in the future. It is not just that we developers want to use this new stuff (and we do), but that market forces often compel us to do so, even when our client needs dictate otherwise. Sure, there are some brave souls who will develop with their customers' best interests in mind, but the system in place is actively selecting against such developers.
Jay White
received by e-mail
More Tips, Please
I greatly enjoyed Jonathan Bruce's article, "5 Surefire ADO.NET Performance Tips" [Database Design, VSM March 2006].
It isn't that the tips were groundbreaking, although they were solid enough. What appealed to me is that they were practical and results-oriented. And that is more than enough to make a good, solid article.
I would suggest that this is the kind of article VSM should do more of in the future. First looks at upcoming technologies are all well and good, but it is articles like this one that make me want to keep receiving your magazine. In fact, nothing would please me more than to see you bring back one of my favorite magazine features from the past: the 101 Tips supplement. I still have my old copies of these, but it would be even better to have tips relevant to .NET.
Ronald Thomas,
Buffalo, New York
No Need for (Most) Third-Party Tools
I just completed the Readers Choice Awards survey. You'll find that I didn't check even one item. I'm certain that within each group there is one that stands out as better than the others, but I have to admit that I've never used any of them. Ever.
You're probably thinking: How can that be? Is this a real programmer? Are there no challenges that require these tools?
I'm currently a Senior Systems Analyst with a consulting firm where we support a number of automotive companies. I've been programming for more than 20 years on PC platforms, back to the days of TRSDOS and CP/M. I've programmed professionally in BASIC (20 different kinds at least), Assembler, C, C++, Delphi, Java, C#.NET, VB.NET, and SQL, as well as VBA in Access, Excel, and Word.
But I've never used an add-on component that didn't come with the development tool, and I've never found the need to. I have had the opportunity to use many charting tools and report-writing tools, but none of these tools provided anything essential to fulfilling our business needs at the time. Excel charts are great. They embed easily into any COM application. Unless you are doing scientific charting, you'll never need anything else. Access does a great job of reporting; it's also easy to use and powerful. Crystal reports fill in the reporting for the remaining problems, including Web applications, where some simple HTML works wonders if you put in the effort. You can create Adobe PDFs easily and reliably with the cheapest version of the Adobe tools, even in a batch production environment.
I know that the magazine gets 99 percent of its revenue from the advertisers, and I do appreciate that third-party tools fill a need. However, when you have an awards process, please don't forget that the vast majority of business applications don't need these third-party tools. It's hard to justify the cost of any of these tools when the development environments provide such power out of the box. You might want to include the basic development tools in the lists, or create a separate category for them. I noticed you had Dreamweaver, but no Visual Studio. They are in direct competition, so Visual Studio should have been included. It would have been the top contender in most every category.
Thanks for the opportunity to fill out the survey. Please don't exclude it just because it's blank.
Dave Newman
received by e-mail
Visual Studio is not included in the survey because the magazine is about Visual Studio. We feel it is unfair to the third-party component and tool providers in the survey to include Visual Studio (or other tools that ship with Visual Studio in the box) in this survey. We want readers to tell us which tools work best with Visual Studio—Eds.
The Impact of Patents
They say that the past repeats itself and we often do not learn from our mistakes.
Patrick Meader's editorial on the vulnerability of SOAs to patent infringements highlights a longstanding problem in the U.S. technology sector [Editor's Note, "Patents Present New SOA Vulnerability," VSM April 2006]. Coming from a telecommunications background, I am acutely aware of patents and the potential impact they may have on an organization. Go to any large call center across America, mention the name Ronald A. Katz, and eyes will roll. Many companies have fallen prey to Katz's broad array of technology patents.
I find the RIM ordeal and your article to be a validation that we don't learn from our mistakes. The fact that technology companies have basically ignored any attempts to modify patent law exhibits a level of contempt beyond compare.
I like to compare this situation to that of an automobile. In the case of the Katz Call Center portfolio, it would be equivalent to obtaining a patent on a lug nut and then expanding that patent to encompass the entire car. With patent law so skewed, it should be four years of mandatory course work for every engineering student. Failing to account for patent law practices is gross negligence at the business-model layer of application development.
James Middleton
Panama City, Fl