Although I don’t write much code in my daily work as CTO, I do occasionally dip my toe into the code-writing waters. Because
I come from a development background myself, I take an active interest in the procedures and processes of my development team.
Generally, though, I let those guys run free as long as they are using basic best practices to get their work done. Those
basic best practices include simple things such as source-code control, reusable code writing, peer code reviews, and most
importantly, consistently hitting project milestones with code that works and scales.
As a Java shop, we have our choice of dozens of tools to produce our code, but our developers have opted for the humble text
editor. Our developers use a wide variety of text editors within the team (UltraEdit-32, vi, and Emacs), but each developer basically sticks to the simple text file environment. Our team is highly productive and
probably the best at hitting deadlines that I have ever managed, but when it comes to writing code, IDEs (integrated development
environments) just leave them cold.
I started thinking about IDEs again recently when I decided I wanted to really learn Java after a number of false starts in
the past few years. This time, I had a real-world mission in mind — I wanted to learn how to extend our Salesforce.com implementation
using the vendor’s sforce development platform. The Eclipse SDK, an open source IDE from Eclipse.org, seemed like a quick way to get started based on what I had read. As any good manager
would do before diving into such a project, I asked the developers on my team why they had chosen not to use IDEs to do their
work. The answer was pretty predictable: They thought the level of abstraction that visual IDEs brag about was more a detriment
than a benefit. One of our developers compared building code in an IDE to using a WYSIWG editor to build Web pages — doing
HTML by hand results in cleaner pages, and you know exactly how they work when you’re done.
We’re not the only ones who prefer to get things done without IDEs. As I write this column, there are five open software developer
positions at Overture, the advertising services company purchased by Yahoo last summer in a deal valued at $1.6 billion. The
requirements are fairly typical for anyone looking for Perl/C/C++ developers, but one point caught my eye: “The team does
not use IDEs to develop applications.” Although this might appear to be an unusual statement to make in a job posting, I admire
its directness. It will filter out vast numbers of applicants who might not be a good fit for the existing team.
The IDE debate will probably continue until the end of time. A surprising degree of passion flares if you bring up this issue
with developers. But does it actually matter? The answer, like any dealing with the ambiguities of IT philosophy, is yes and
no. As long as your developers produce quality code that they can debug at the lowest level when necessary, the IDE debate
is probably more of a cultural issue than a technical one. Consistent, quality code delivered on time trumps the means of
getting there; however, culture matters within a development team. If your development team spends a lot of time debating
the merits of writing code in an IDE or a simple text editor, they probably won’t be incredibly productive. The important
thing is to choose the route that makes your team most productive — and execute.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
