Slashdot Log In
Same Dev Tools/Language/Framework For Everyone?
Posted by
kdawson
on Tue Jul 08, 2008 12:06 AM
from the one-size-fits-none dept.
from the one-size-fits-none dept.
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?"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Choose them all under one. (Score:5, Interesting)
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.
Re:Choose them all under one. (Score:5, Insightful)
Whoa, whoa, whoa! You forgot the most important thing: source control!
Perforce is probably good for larger companies, while Subversion or Git should be good for small/medium companies.
Parent
Re:Choose them all under one. (Score:5, Funny)
If it's big enough you can rely on picking the right tool for the job... developers simply chose the tool and compete based on who can implement the software best measured by customer satisfaction reports, rather than bugs or performance. Rather than directing outcomes we foster a system based on evolutionary theory. Developers are pitted against each other, and the weak developers get stabbed or maybe scalped. The Head Developer wears a necklace of threaded ears and walks around the office taking his share of the women and of food and clothing. Every night a fire burns and the drum beat calls developers out to compete for their very lives. Generations later Alpha developers will rise to feast on their flesh, crush our enemies, see them driven before us, and we will hear the lamentations of their women.
This will really only work at large companys though :(
ps. Hi gordon in #jelliffefans...bring your A game!Parent
Answers to your 3 questions (Score:5, Insightful)
1. Slashdot will think that you should be able to use anything you damn well please as long as it's Open Source.
2. Yes, especially if the people who sign you paycheck tell you that's what you have to do.
3. Maybe. A lot depends on how well the team is managed.
Standardize the RIGHT tools (Score:5, Insightful)
Management invariably tries to standardize the wrong tools because they have no idea how software development works. They think in terms of the IDE as "the tool set" rather than the MAKE or ANT build systems, compiler toolchain, version control, and other behind the scene tools.
If you want the standardization to go well, make sure the build tools are standardized. Once anyone can build the project (IDE or no), it won't matter what the "standard" IDE is. (Unless it's Rational Application Developer. That's just a piece of shit right there. Universally agreed upon.) Developers will still download their own editor or IDE tools to make themselves happy without disturbing the greater whole.
Re:Standardize the RIGHT tools (Score:5, Interesting)
Parent
Re:Standardize the RIGHT tools (Score:5, Informative)
That combination is better than just free as in beer... it's also free as in free speech! Subversion, Ant, and CruiseControl are all Free Software.
Parent
Re:Standardize the RIGHT tools (Score:5, Insightful)
Project management tools: version control, bug tracking tools, etc. Are important, and should be mostly standardizable without impacting upon any project.
These are supporting tools, but your version control system is not a development tool like your compiler or IDE is. (It's more of a development tool like Visio for making your UML diagrams or Word for making your documentation is).
Adjunct tools are all readily standardizable, and useful to standardize (everyone uses Visio or uses DIA, or Poseidon -- so everyone can read your files), just stay away from the language the code is written in and the exact tool used to type it.
It makes sense, even to use a common repository for all projects, and one private web site to track bugs for all projects (divided into their own categories/administrative domains, of course)
Just don't standardize on windows-specific tools like VSS or SG if platform development is mixed (I.E. some software needs to run on other platforms), or use version control that has to be IDE-integrated.
Unfortunately, many developers rely on their IDE like a crutch and need it to be able to build things for them.
They are particularly fond of tools like Visual Studio that try to do everything, even decide how building will work
Build processes are inherently project-specific and depend on which files need to be compiled and which libraries need to be linked.
Builds are not much more standardizable than choice of language.
But should be standardized for each project. I.E. Everyone working on a project using language X, should use the same compiler, so developers will have consistent results.
And there should be standardized (non-conflicting) build tool installs for various projects that use build tool X, so again, there are consistent results when different developers attempt to run a build on their workstation.
Parent
A gross misunderstanding of the process (Score:5, Insightful)
Sure, and while they're at it, let's give all the mechanics just one size of wrench and screwdriver.
This policy shows a gross misunderstanding of the engineering process, and of what computer science is. Any computer scientists worth his/her salt should be expected to learn whatever tools are needed to get the job done. And conversely, each project team should be free to evaluate the best tools to get each job done.
It's not unreasonable to have guidelines and even strong recommendations; for example, a company could discourage csh scripts in favor of bash because of the known problems with csh. But to think that C/C++ can substitute for a scripting language or vice versa, or that even a language like FORTRAN has no purpose, completely misses the point.
When I was at Stanford, we got ZERO units for learning different programming languages. We were EXPECTED to learn C, C++, Lisp, and about a dozen other languages, before we could call ourselves computer scientists. If anyone thinks that limiting a computer scientist's choice of tools is a good idea, you should kick that manager to the curb.
Start sending out resume... (Score:5, Insightful)
I am sure we could all make due building every road out of steal, but it would certainly be a little expensive, because if we need to build everything out of the same material because all road builders need to be interchangeable, than we would never be able to build a bridge over say San Francisco Bay with using stones...
Re:Start sending out resume... (Score:5, Insightful)
Parent
Re:Start sending out resume... (Score:5, Funny)
The only thing worse for it is hiring "managment consultants" to "streamline" the process.
Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
Parent
It depends on how varried your projects are (Score:5, Insightful)
It depends on how varied your projects are; if all you ever do (as a company) is produce slight variations on a single theme, it should go fine. If you need to develop everything from hard real time embedded apps to web 2.7 social networking goo, you're screwed.
--MarkusQ
No way. (Score:5, Insightful)
Where developers must interface, such as coding style, source code repository or corporate blog? Yes, it makes sense. I may not *like* a coding style, but if management at a large company told us to use one, I'd at least understand why. IDE? OS? Compiler (except for the one that actually builds the product)? No, NO, NO!!! A thousand times, no! Why? Because you're just going to stifle creativity.
Management point: IT needs to work on the same thing. Counterpoint: IT is often clueless. Developers can almost always troubleshoot their own systems.
Management point: Ensures software licensing compliance. Counterpoint: None really, they kind of have you there; but since most companies have a policy against installing unlicensed software anyway, punishing developers by forcing them into a cookie-cutter workstation isn't going to solve that problem.
Management point: puts them all on the same page, builds team. Counterpoint: It makes development less a "collegial" environment, where diverse ideas are explored, and more of a "command" environment. Developers are notoriously intolerant of following orders simply for orders sake.
Newbie developers coming right out of school might not mind being told to use all the same tools; but experienced developers might feel otherwise. If you want to annoy experienced developers who know all the ins-and-outs of their particular toolset, then go right ahead. Then, wonder why nobody comes up with new ideas, makes comparative observations of one system against another, or develops an alternative approach that goes beyond the status quo. Wonder why people who don't drink the kool-aid on your particular toolchain leave for greener pastures. Wonder why you don't have any in-house expertise on any other system when your chosen flavor is no longer sweet.
Re:No way. (Score:5, Insightful)
Unless they all operate on the same meta-data the foreign tool is out. My boss thinks the same way you do, every one is allowed to use any damn tool they feel like, with absolutely no bounds.
I work with a guy who insists on using Visual Studio, as nearly as I can tell, because he's unaware that there is a multi-tab text editor outside of VS. So, everytime I have to take over a project from him, I have to go figure extract what files are being build, and then port it into the production system, every other developer on the project uses. Because this is such a hassle, the guy will do updates and commits on an interval measured in months, where as every other developer does them on intervals measured in hours. So along with everything else we have to deal with, when he commits his code, he generally will blow away months of someone elses work because he can't be bothered with learning how resolve conflicts, and it'll never integrate cleanly. We'll spend a week just trying to undo all the damage he'd done. All because he can't be bothered to use the same toolchain everyone else on the team does. It also means I have no commit history, no commit comments, and nothing I cause use to do research on to figure out how the software evolved.
Because he uses Windows, Visual C++ compiler, on an AMD 2.8GHz machine and does all his profiling, it's trivial to go make improve his codes performance on Linux, g++, on an 1Ghz Via C3 (which is the deployment environment for the embedded system). As he works on the single most performance critical aspect, it's more then a bit frustrating. Especially as the code has extreme and unnatural things done to it to the parts that are slow under his one off development environment, but those aren't the parts that are slow under production.
For things like Java, I've learned the hard way, that we'll only have one setup of meta-data. It's terrible frustrating to have all of the corporate standards setup correctly in say Eclipse, (checkstyle, code generation, auto-formatter, unit testing, test coverage, find bugs, PMD, warning levels, etc, etc), and then have some jackass continually commits code that upon contact with a properly configured environment will be flagged as a violation of the coding guidelines, or generates huge numbers of warnings if only he'd turn on the already agreed upon warnings.
I've learned, that there is one set of production meta-data used to do a production build. While we can argue over how we maintain that set of meta-data, once that decision is made all tools must use that meta-data directly (they can translate it from one format to another, as long as it does that automatically, like Maven can for some IDE's). So if we use Eclipse, you can use any tool you want, as long as it reads Eclipse meta-data. If we choose Ant, then you can use any tool you want, as long as it does Ant meta-data. If we choose GNU Build system, you can use any platform and compiler you want, as long as it uses the GNU build system. The one hard and fast rule I have for the meta-data is that it must be possible to build from a command-line in an automated way. It can be obscenely difficult to do (like say Eclipse), but it must be possible.
I've generally learned that anybody who won't agree to use a consistent set of tools with the rest of the team, is a prima dona and is in dire need of a lesson. Yes, I know my toolchain stone cold (gcc/g++, and Eclipse). However, if there is a consensus to use a different toolchain, I'll learn a second one stone cold. I've learned tons about bash, gcc, g++, the Borland compilers, Visual Studio, a number of embedded compilers, Watcom, XCode, the NeXT Objective C IDE, NetBeans, Eclipse, CVS, SVN, Git, Monotone, Arch, Mercurial, Ant, Maven, GNU Make, GNU Auto{conf,make}/libtool, SCons, and probably a couple of others I've forgotten (I've known bits and pieces of several scripting languages, but none well enough write home about). I've learned the best practices of them all when I used them. Given m
Parent
It's dumb. (Score:5, Insightful)
27 years experience and I've heard this idea before. It is dumb.
2-3 languages- sure. One for gear-head, one for report/data mining at least.
5 languages at the same company is a problem- but 1 language is a problem too.
Better to choose a process than an environment (Score:5, Insightful)
Languages are just details. It's far better for developers to standardize on a set of processes - documentation, as-builts, code review, unit tests, TDD, scrum, FDD ... pick a set of development processes that make sense for your company and project. Some methodologies always make sense - if developers write clear, concise docs and as-builts for their set of coding responsibilities (yeah, right :rolleyes:) then a good developer can pick the code up and run with it regardless of the language.
Language is just syntax. (OK, it's mostly syntax :p) But the primary point is that most developers have had a wide range of language exposure. I don't know Ruby nor Python, but I've done a helluvalota PERL, JavaScript, and C/C++ and it'd be fairly trivial for me to pick up a well documented Python app and maintain or extend it. Just give me a good O'Reilly book. It takes longer to figure out what the actually code is doing than to understand the syntax and semantics anyways.
Two (Score:5, Interesting)
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.
Does everyone know the same languages? (Score:5, Insightful)
Perhaps your environment is unique, but I've rarely seen an organization capable of moving people around at will, simply because not everyone has the same skill sets. Even within the Web development paradigm, there's always the "SQL guy", the "CSS guy", heck, even the "regex guy" who's been writing Perl since he was a kid. making that guy use Eclipse instead of vim and puTTY seems counterproductive to me, even if you happened to have someone with those skills on each team.
Doom!!! (Score:5, Insightful)
Look for another job. When upper management sticks their nose in with the rational that you described, doom is just around the corner. The problem is simple. How do you get the best performance out of your best people? The answer is not: Fit them all into the round hole. The correct answer is: Let them use the best tools possible as they perceive them to be.
Okay, languages need to be standardized, but after that, the environment needs to be perogative of the developer.
Nuff said...
I have mixed feelings.. (Score:5, Insightful)
I used to think that a programmer's tools are sacred and you should basically let people use whatever they feel they are most productive with, but I'm starting to see problems with that, at least in big organizations..
First, IDEs - I've worked on teams where 3 different IDEs were being used by different members of the team - IntelliJ, NetBeans, and Eclipse. It worked fairly well and no real problems came about as a result of the different IDEs. I've also been in training sessions where everyone is using the same IDE except for some crackhead insisting that their IDE is better and that they can't switch to Eclipse even just for the training, and everyone in training has to wait for half an hour why the instructors try to help them figure out why stuff isn't working in their IDE.
Second, platforms/libraries/frameworks - There are really a lot of valid reasons for standardizing the platforms, libraries, and frameworks your organization uses. You have better internal support, can leverage work done by other groups, and training is easier. Being able to switch people around easily is perfectly valid as well - people leave, get promoted, need a break from their project, want to explore different career goals, etc.. Plus, I think it is good to send people off to other projects to learn and share good practices. Having a standard set of tools makes this relatively easy - all you really need to learn on a new project is the business side of things.
That said, there isn't a one-size-fits-all solution, so it probably makes the most sense to pick a standard set of tools for common project types. If a project needs to deviate from one of those standards, that is fine, but they need to make their case for doing so.
So for full-blown enterprise apps, the standard may be Java EE. For smaller apps, it might be Rails or Grails. For desktop apps, you might mandate .NET. Then if someone says "Hey, it would be cool if we wrote this small app in Python", then they could do it, but they would have to show that the benefits gained by using Python in that scenario would outweigh the costs of using a non-standard platform.
GCC + Make + Emacs (Score:5, Interesting)
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.
Root cause (Score:5, Insightful)
There is definitely value in having the members of the development team agree to a set of tools around which they can share common experiences and exchange solutions for problems that come up. That's fine. What scares me about your question is that it is driven from above,
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.
Developers are not plug-compatible interchangeable parts that can be slotted in and out of various projects according to shifting needs. It doesn't matter if they all know exactly the same toolset or not, dropping Jane from the accounting project who has been around for a couple of years in to replace James in the supply-chain project who left because he got married and his wife is taking an internship at a distant hospital and expecting equivalent results demonstrates a vast ignorance of how developers become productive.
Nearly every company's management wants to imagine it can standardize developers for a lot of bad reasons -- because they believe that gives them leverage over someone who has deep domain knowledge and can't easily be replaced with a junior programmer for example. Or they imagine they can save money by buying bulk licenses for a product from a vendor. Beware of management playing golf with software tool vendors, you'll get stuck with some POS for sure.
Perhaps going to management and suggesting that the developers collaborate to nominate a selection of acceptable toolsets from which management can select would work, but that kind of suggestion never seems to be taken very well by the suits.
Re:Depends (Score:5, Interesting)
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.
Parent
Re:EPIC FAIL! (Score:5, Funny)
Parent