Slashdot Mirror
Same Dev Tools/Language/Framework For Everyone?
AC writes "Upper management of the company I work at recently declared that all new development should be done with a single combination of development tools, language, and framework. The main rationale is that people can be relocated from one group / project to another faster, because they don't need to learn a new environment when they switch. Of course the chosen language / framework used by everybody does not need to be the best tool for the job, but it should be good enough to allow every project to get done. What does Slashdot think about this? Is it OK to use the same development tools and language for every project, instead of choosing what fits best? Will the time saved be sufficient to offset the time lost to the 'not the best tool for the job' environment developers will be forced to use?"
We frequently encounter this issue with our clients (government, military, and commercial). We know that this can be a very bad thing if they capriciously apply it across the board. What we have recommended allows for the most flexibility, while minimizing the "tools". In order of importance.
1. Cygwin (0$)
2. Eclipse (0-250$)
3. Teraterm (0$)
4. Adobe CS whichever (900-2500$)
5. Microsoft Office 2003. (400$)
This would allow any team member to move from one workstation/area of work to another without too much effort.
As to the language, we recommend that one be chosen for "prototyping/scripting" and another for "enterprise" development.
With Cygwin you get the CM tools, build tools, perl/bash/etc. (Already included tool set under Mac/Linux/Unix...) With Eclipse you get every thing too. (works on all OS) Teraterm nice term, just don't like putty myself. (not needed outside of windows) Adobe for those that like spending money. (Mac/Windows) Office, they are going to buy it anyway.
It's lame to reply to myself, but I forgot something re: development tools.
Don't dictate what your developers use, if it's possible. Case in point: In my current company we are building a VB.NET web application. There are six developers and five of us use Visual Studio, but the tech lead does not, he uses VIM. I was amazed by this, but after seeing him wrangle some text with that thing, I can see the value over an IDE, although I still prefer its warm confines because I've come to rely on the bells and whistles.
BUT, this works only because he has a build system where he does not rely on the VS project files, only the source code, resources, images, etc. The end result is the same as if you had compiled the thing inside Visual Studio, except that you used only the compilers. This is very cool, and while I don't fully understand the build files, I can see how that's a definite advantage. The scripts even pull the source off CVS and everything.
My point I guess is that you shouldn't tie yourself to development tools, if possible. That's just common sense, and at the same time you'll allow developers to use the tools they prefer. That makes for happy developers.
Maybe one of these days I'll try VIM or EMACS, or maybe I'll just stick with the IDE. But at least I know I have the option.
Subversion + Ant + CruiseControl = source control with fully automated builds and reporting and it's free (as in beer).
A similar question came up roughly a year ago on slashdot. My recommendation is to chose two: one "scriptish" language (PHP, Python, etc.) and one strong-typed language (Java, Eiffel). C# is sort of a compromise between the two, but marries you to MS (so far), which may bite you in the future like VB6 did.
Table-ized A.I.
Makefiles are text files, and completely tool agnostic. By standardizing on Make, you don't paint yourself into a corner with a single toolchain.
Emacs has editing modes for many languages and file formats. By standardizing on that, you don't paint yourself into a corner, unlike a single language IDE. (Also, those who prefer vi can still use Emacs in viper mode, so Emacs is a more flexible choice than vi for the company).
GCC is a compiler collection, with support for many languages. By standardizing on that, you don't paint yourself into a corner with a single language.
Best of all, these tools don't take up a lot of RAM, so the development machines will be responsive without beefy hardware.
I'm in academia, where just about the opposite prevails: you can use whatever you damn well please, and generally PhD students don't even get that much in the way of hard-and-fast rules from their advisors, so they use what they please too, as do half the research scientists and post-docs. The results of that are why companies consider standardization.
The main problem is that, while experimenting with lots of languages and using languages perfectly suited to a particular task is nice, doing it too freely makes for a nightmare if you ever want to combine things, have a programmer of one system help out on another project, etc.---just the sorts of issues that prompted this question.
My current research project's codebase, partly inherited, partly pasted together from components that were lying around the lab, and partly of my own doing, using nine languages, as a result of everyone using whatever seems like the right tool for each job. There's a C backend for one part and a C++ backend for another part; an AI component in Lisp; some GUI and glue-y stuff in Python; other GUI stuff and some other AI stuff in Java; some text-munging scripts in Perl; some number-crunching in Ocaml; some parsing and god knows what else in Haskell; and some other AI in an in-house language that compiles to Java.
Now some of those tools were indeed exactly the right tool for the job. But this is not ideal to maintain, and it's nearly impossible to ship to anyone who isn't me in a way that a mere mortal could get the code built and running.
Oh, and there's some other projects in the group that use C#, and one that uses Scheme, if I want to go for double-digits...
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Sounds like Stanford taught things the right way.
Just last week, I was thinking about this. The University of Texas (where I went) had a similar philosophy when I was there as well; the goal was to teach the concepts and how to learn new languages. We groused about it incessantly at the time, but looking back over how my career has progressed and how I've been able to adapt to new technology, it was absolutely the right education.
Consider this: At the time I started my Freshman year in college, the Fall of 1991...
The most basic elements of what we develop with today didn't even exist, and those that did exist were in nascent forms that they today barely resemble. Even ANSI C got a major update 8 years afterwards with the C99 standard -- which is nine years ago.
But wait, there's more!!!
When I was in grad school at UCSD, I took a class on Software Evolution. The instructor would give us a project, and every couple of weeks ask us to make changes to the project as our next assignment, to expand the project's capabilities. We were given the freedom to choose whatever means we wanted to pursue this goal. The initial assignment was to generate a simple web page.
A friend of mine chose to use Perl. I asked him if he knew Perl, and he said, "No, but I can learn how in the time it takes to implement this in any other language, and with each new assignment I can just write a whole new script."
He was the only one in the class to finish every assignment.
The moral of the story is not that Perl is something wonderful, but rather that Perl was the appropriate tool for the job and that learning how to use the appropriate tool takes less time than using a tool you're familiar with that doesn't work so well. Consider chopping down an overgrown pine tree. If you know how to use a hand saw but not a chainsaw, the guy who uses a chainsaw is going to hack the tree down in less time regardless of whether he has to read the manual to learn how to use it. (And then after that, he'll know how to use a chainsaw on other trees, too.)
So... yeah.