Recently I needed to work on a Java coding project, which regular readers will know is not my favorite thing to do. To plan for the project development I searched through the most popular Java IDEs including Eclipse, JBuilder, and NetBeans for a feature set comparable to the features I use in Microsoft Visual Studio and the Microsoft .NET Framework. I was disappointed to find that not one of the Java IDEs was even in the same ballpark as the Microsoft environment. This reinforced my opinion that the Microsoft developer products are the best in the industry. I like the rich set of components in Visual Studio/.NET that take care of the heavy lifting required to implement rich UI objects and even bind those interface objects to the database. Many times all I need to do bring these components together is use a few lines of code in the components’ event handling routines.
Visual Studio Versus Java
Although it’s true that I’m more familiar with Visual Studio than with the Java IDEs, I was surprised by the complexity of the Java IDEs. I found them difficult to use; they implemented only a subset of the features I’m used to. Java developers are free to disagree with me, of course, but I need the features Visual Studio 2008 offers: rich project templates for web windows, mobile devices, web services, and even setup projects; a super-rich graphical design environment with over 60 different components; IntelliSense; integrated debugging; and multiple platform targeting. No Java IDE comes close to Visual Studio’s total package. And a couple of the Java IDEs were buggy to boot.
What’s the Problem with Productivity?
A word of caution: the fact that the Visual Studio features boost productivity is paradoxically a potential pitfall. This has nothing to do with their code quality, which is rock solid; it’s about the quick-fix mindset that they could foster. Developers don’t typically have this problem using the Java tools because they make you work at every aspect of the project. It’s not so easy to lapse into the quick-fix mindset when you can’t take big parts of the project for granted. The Microsoft marketers tell developers that the Visual Studio features enable productivity because when we don’t need to write as much code we’re freed up to focus on business requirements. That’s definitely the right message, but overzealous developers can misinterpret it to mean that they can spend less time coding all aspects of the project. Sometimes this might be the case, but the danger is that this quick coding mentality could be applied to the more time-consuming details that really can’t be automated or quickly churned out.
In several development projects I’ve seen eager-to-please, overly optimistic developers underestimate the time required to complete critical project milestones. They wind up shortchanging themselves. Instead of planning to spend more time focusing on the difficult problems such as correctly implementing business requirements and robustly handling user errors and exceptions, they plan to complete the interface on schedule but end up not having enough time to handle the hard parts of the project. In all but the simplest of projects the end-results may look good but they might not work the way users expect and they won’t be robust enough to handle unexpected runtime conditions.
Good Code Versus Great Code
Don’t get me wrong, I love the productivity features in Visual Studio, and I’m hopelessly spoiled by them. But by the same token I resist thinking that the rapid development they enable would apply to all aspects of my projects. Remember that your ultimate goal should be to write better quality code not to just write more code faster. Don’t let Visual Studio’s fantastic productivity enhancements beguile you into reducing your project development estimates. Improved productivity is good, but robust code that truly solves business problems is great.
If you want to share your experiences about using the Visual Studio productivity features or the Java IDEs, drop us line at [email protected] or [email protected].
