Amazing how discussions about IDE's always seem to draw so many responses...
Good points Mike, and well put. I totally agree with your statement
that tools are meant to work the way that you want/need them to - not
the other way round.
As with sex/religion/politics, it is just plain rude/stupid for
management to try and persuade/mandate anyone to think/do things their
way. Sure, show me what your favourite tool can do - I'll probably
learn something new and maybe even become a convert eventually. But
managers and team leads should be aware of the psychology involved:
people build up habits and don't like being forced to break them. A
tool that makes one person productive won't necessarily improve
someone else's productivity.
A team should agree on the target build platform, but individual
developers should be free to choose whatever tools they want to
develop with on their individual desktops - as long as the code they
write compiles and runs on the "mandated" target platform.
A simple rule of thumb: tools that are to be shared between developers
(target OS, DB, build system, version control, issue tracker) should
be mandated (or, rather, agreed upon in a democratic/civilised/mature
manner without any need for "mandating"), whereas tools that are used
by individual developers (desktop OS, editor/IDE, issue tracking
client) should be left up to individual developers to choose for
themselves.
For example, a system I started developing in 1995 had the following
target platform:
Language = ANSI C
OS = NCR Unix SVR5
DB = Sybase
Build System = Makefiles
(We didn't use any version control or bug/issue tracking system in
those days...)
I actually developed the entire system on a copy of NeXTSTEP 3.3 (for
Intel), which, being BSD UNIX-based, had a C compiler, Make, an editor
and even shipped with the Sybase client C libraries (dblib). On top of
that, it had the cleanest, most polished user interface in existence
(then, now re-incarnated as MacOS X), but few people knew about it at
the time due to the (overly noisy) launch of Windows95 that same year
(Phwah!).
I took an active interest in NeXTSTEP with it's balance of power
between a slick GUI and a powerful command line. I was simply not
interested in using Windows or developing on a crude command-line-only
UNIX telnet session. I developed the entire system on NeXTSTEP,
copying my changes over to the build machine daily to ensure that it
still built and ran on the target platform.
Did it matter to anyone that I used my personal prefered tools? Not at
all. I may have stimulated some interest in some alternative tools
that no-one had used or even seen before (or, more likely, they just
shook their heads at the long-haired hippie asserting his
individuality). But at the end of each day, the only thing that
mattered was that it built and ran on the shared target platform.
Fast forward to my current project at Oracle... our target platform is:
OS = Windows
DB = Oracle
Language = Java (JDK1.5)
Build System = Maven (Great tool! Spend time *coding* - not writing
complex build systems)
Version Control = Subversion
Issue Tracking = Internal Bug reporting system
The OS choice is unfortunately due to a dependency on one particular
application, which is Windows-only and outside of my control. The DB
is Oracle for obvious reasons. Likewise with the language (though I
would love to dabble a bit with Python - but I digress: this is a Java
User Group...). I was actively involved in introducing Maven and
Subversion into the team (migrating them away from Visual SourceSafe -
yeah!).
Being Oracle, most developers here use JDeveloper, which has some nice
features and has an embedded Servlet container (OC4J) to speed up the
devopment cycle. However, I love using the command line and (G)Vim.
So, I set up the project in such a manner that we follow the Maven
conventions for our source code directory structure, adhering to
Maven's philosophy of prefering convention over configuration, thereby
wasting almost no time on the build system.
Now here is the crucial point: I adapted the JDeveloper project files
to follow the Maven conventions. It expects source code to be in the
same place that Maven does, and it places the compiled class files and
JARs/WARs in the same 'target' directory that Maven does. ie. we
adapted the tool to work the way we choose to - not the other way
round!
The result? As Mike mentioned, the build process is completely IDE
neutral. Developers are free to use whichever editor/IDE they choose
to on their desktops - as long as what they write builds and runs on
the target platform. And the target build platform doesn't require a
bleedin' IDE! We want to automate the build process and write scripts
and stuff - hence we rely on command line tools only on the target
build platform. So, while many use Windows with JDeveloper and
TortoiseSVN on their desktops, I use Ubuntu Linux with GVim and
Subversion on the command line. It really doesn't matter, and it
shouldn't.
A benefit of this is that it makes most IDE debates pointless. I don't
care if you think NetBeans/Eclipse/JDeveloper/IJ/whatever is better
than what I use. Mandating a specific IDE is as pointless as mandating
a specific Subversion client. It boils down to personal preference at
the choice is best left to individual developers.
I must add that I have been fortunate to work almost always work on
systems that are owned by the company I work for, ie. the client has
absolutely no say (intference) in the choice of IDE.
Anyway, enough already from a lurker who seldom contributes, but then
writes an entire essay (rant?) to put a simple point across... ;)
Cheers,
Johan.
On 11/2/07, Mike Morris <[EMAIL PROTECTED]> wrote:
>
> Brian Silberbauer wrote:
> > By client I meant IT department type clients
>
> I stand by my point. Back in the dark ages when I was involved in
> making such decisions and advising IT departments on tools, process,
> teams, etc., I still had the clear objective to make the process IDE
> neutral so that different developers could choose the tools they prefer
> best. I still believe this to be a good objective; a development
> manager mandating "All developers will use X" smacks of laziness,
> insecurity or stupidity. (In which case my sincerest advice is "Run
> Away!" (picture large wooden rabbit flying over castle wall...))
>
> > I think as java developers we are used to alternatives (in terms of
> > libraries, OS and tools) and that makes as more agile and fear change
> > less.
>
> Its not fear of change, but that I simply can't be bothered to learn
> another tool's annoying little differences. As you say, they're all
> pretty good by now. What kept me away from IDEs for many years was
> /exactly/ the idea/attitude/philosophy that "You have to learn the Funny
> Little Ways that this tools expects you to work." Well ${bother} that.
> Tools are meant to work MY way, not the other way around. Good tools
> stay OUT of your way/face. (I know, I know; it's not a perfect world,
> but we're setting a target to aim for, here.)
>
> --
> mike morris :: mikro2nd (at) gmail (dot) com
>
> http://mikro2nd.net/
> http://mikro2nd.net/blog/planb/
> http://mikro2nd.net/blog/mike/
>
> -- A day without chillies is a day wasted --
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CTJUG Forum" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/CTJUG-Forum
For the ctjug home page see http://www.ctjug.org.za
-~----------~----~----~----~------~----~------~--~---
