IDEs are, like, so yesterday
When was the last time you asked your general contractor if the company had a power-tool standard, and whether it was Makita or DeWalt? Does your auto mechanic use wrenches from Sears or Snap-On?
When I talk to carpenters, electricians, plumbers and other professionals, I’m engaging them to perform a task. I assume that they have the the right tools for the job, and they know how to use them.
It’s not that simple with software development. Yes, our industry has reached a level of maturity. We can safely assume that all the tools are, generally speaking, pretty darned good. You can write great code with Eclipse. You can write great code with NetBeans. You can write great code with Visual Studio. You can write great code with BEA Workshop and CodeGear JBuilder and Apple Xcode and Oracle JDeveloper and the IBM Rational Software Delivery Platform and you-name-it.
But having an IDE is not enough. The fact that you’ve bought a development environment that integrates many functions is not nearly enough.
You don’t expect a drill to help ensure that your house meets safety specifications. But you could, and should, expect your software development tools to play an active role in helping build better business applications.
What matters, truly, are platforms and applications. You don’t engage a plumber to use a welder and pipe-cutter; you engage a plumber to stop a leak or install a new bathtub in your home. Similarly, enterprises don’t hire programmers or engage consultants to use Eclipse or NetBeans or Visual Studio. CIOs and CTOs pay these people to develop applications that advance the business.
That’s not to say that tools aren’t important. Carpenters need saws, plumbers need torches, and programmers need IDEs. Picking the right tool for the job is essential. However, the metric shouldn’t be “does the IDE enable the creation of good code.” They all do — just like both Makita and DeWalt drills can make clean holes, and Sears and Snap-On socket wrenches can all remove spark plugs.
Writing good code and fast code is easy for a professional developer. We’ve done that, even before today’s crop of super-sophisticated IDEs. The true test for tools makers is: How does their tool help your enterprise developers solve business problems? Do they support your vertical market or vertical application? Do they enforce security? Do they nurture best practices? Do they support the full application life cycle, or smoothly interoperate with other ALM solutions?
Of course, we don’t expect our cordless drill to interoperate with our welding torch and with our screwdriver set. That’s where software development and plumbing are just a little bit different. Too many writers stretch this analogy too far. We don’t expect Makita to document New York City building codes, but we should expect development tools and platform makers to worry about Sarbanes-Oxley and buffer overflows.
As I return from EclipseCon this week, it’s clear that enterprise programming isn’t just about banging out code. Not any more. It’s about building business applications. Challenge your tools providers to talk about how their products actively facilitate the creation of business applications. Because you already know that they handle the easy stuff: coding.