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?"

Comments

Choose them all under one.

[jpyeron]

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.

[Anonymous Coward]

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.

Re:Choose them all under one.

[Anonymous Coward]

How big is the company?

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!

Re:Choose them all under one.

[Jurily]

WTF is this crap of "any team member to move from one workstation/area of work to another"?

If someone is good at something, ferchrissake KEEP THEM THERE!

There's nothing more devastating for a developer than to be ripped out of context and forced to learn something entirely different, but just as difficult, just because some braindead accountant thinks all developers are alike.

Please stop that. I think it has a more than measurable impact on productivity, not to mention staff morale.

Translation: everyone who thinks programmers are interchangeable should go fsck themselves with a chainsaw.

A gross misunderstanding of the process

[Anonymous Coward]

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.

Re:A gross misunderstanding of the process

[xero314]

Sure, and while they're at it, let's give all the mechanics just one size of wrench and screwdriver.

I am so sick of this analogy, as it's completely inaccurate. Programming languages, at least full featured languages, are a whole set of tools, not a single tool. Comparing Java to C is more like comparing Craftsman to Snap-on, different brands of tools but they can both be used to do the same thing. If you can give you mechanics a single tool that can be used in all their tasks, like a sonic screwdriver, then do it. If the language isn't full featured, or cover all your needs, then don't use it.

And conversely, each project team should be free to evaluate the best tools to get each job done.

This is exactly what you need to do if you want to guarantee that you have to continue with the team you have or hiring nothing but experienced senior developers. Keep the number of tools simple and you can have a small number of leads and many interns to do the same amount of work with a much higher over all quality and considerably less cost.

If anyone thinks that limiting a computer scientist's choice of tools is a good idea, you should kick that manager to the curb.

If anyone thinks that hiring computer scientist's to do anything other than research and theory is a good idea, you should kick that manager to the curb.

Re:A gross misunderstanding of the process

[Rimbo]

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...

1. The Linux kernel had not yet been released by Linus Torvalds (v0.11, Dec. 1991)
2. The World Wide Web had not yet been released to the public (1993) -- NCSA Mosaic was not to even begin development for over a year (Late 1992)
3. Java had not yet been released to the public (1995)
4. The latest release of Windows, 3.0, was still a 16-bit shell launched (not by default) from DOS.
5. Microsoft Office was just a bundle including Word, Excel and Powerpoint at a discount (vs. their separate costs) and had only existed for one year; it was generally an also-ran compared with Lotus SmartSuite and Wordperfect (e.g., Lotus Ami Pro 3.0 was ranked as the #1 word processor for Windows by PC Computing magazine at that time)
6. The C++ STL had yet to be developed (proposed 1993, released 1994).
7. The first GSM network ever was just being launched; IS-95 (Qualcomm CDMA) was not to be introduced for another 4 years.
8. The Eternal September had not yet occurred (1993)
9. IBM was still the dominant PC maker.
10. Design Patterns was 3 years from publication.

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.

Start sending out resume...

[Fallen Kell]

Seriously get out your resume and start updating it. Once management starts treating all programmers as interchangeable is the day that all things start going to hell. Programmers are not interchangeable, and all languages are not interchangeable. I sure hope you guys don't do anything that requires AI or if you do I sure hope you don't do anything that requires graphical interfaces because you are screwed either way if you need to pick one language.

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...

[alexmin]

"Once management starts treating all programmers as interchangeable is the day that all things start going to hell." - I second that, saw it happened and not once. Usually morale goes right to the crapper. The only thing worse for it is hiring "managment consultants" to "streamline" the process.

It depends on how varried your projects are

[MarkusQ]

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

It's dumb.

[Maxo-Texas]

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.

Re:Depends

[twatter]

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.

Better to choose a process than an environment

[Jabbaloo]

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.

Re:Standardize the RIGHT tools

[mysidia]

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.

Doom!!!

[daviskw]

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...

Re:Standardize the RIGHT tools

[Fred Foobar]

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.

GCC + Make + Emacs

[martin-boundary]

The biggest risk with standardization is that you'll paint yourself into a corner with the wrong tools.

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.

Re:Answers to your 3 questions

[Jurily]

1. Slashdot might as well think that you should be able to use anything interchangeable enough not to make a difference in the long run. Emacs vs. vi comes to mind.

2. The people who sign the paychecks hired you because you know what you're doing, not to be an interchangeable code monkey in need for micromanagement. (Right? If not, RUN!)

3. If you don't "force" the devs to use tools they hate, this is not an issue. If you do, there is no "time saved" to speak of, and management can do nothing about it.

Solve the right problem

[iwein]

First of all, it's a pile of shit and it stinks.

I can show you two programs written in Java that are so different that you wouldn't know it was the same language if you found them in the wild. As remarked before, switching languages is almost never the problem.

The problem is that developers in different divisions are not interchangeable like parts in a machine.

Newsflash: developers are not interchangeable.

If you hire and train in a smart way you might get developers that are smart enough to deal with somebody elses messes and that leave messes that can be dealt with by somebody else.

The first thing that a developer will say when he starts at an existing project: "This should have been done differently, using language Y, framework X. This is a pile of shit!" (Y and X varying among developers and over time). Doing everything with language Y and framework X doesn't fix anything though, because they are in constant flux.

Newsflash: projects are not all the same.

If all your projects are the same you should come up with a way to let the business owners roll out variations on the theme and get the hell out of there.

The interesting bit about writing software is to learn the domain and find the programming model that works best there. Then simplify it until you're done.

This is not to say that developers should be allowed to try anything new. Reducing the choice a bit (dare I mention web frameworks?) makes a lot of sense. Eliminating all choice is just plain stupid.

If you dumb down the organization by eliminating evolution of the programming model and robbing the developers of the freedom to do what makes sense, you will see the smartest developers walk first. The next thing you will see is a huge drop in the rate of change in the products and the responsiveness to the market. The last thing you will see is lawyers.

A quote from a friend

[david.emery]

"Management standardizes that which they do not understand, to relieve them of the responsibility of having to think about it any more..."

dave