Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Same Dev Tools/Language/Framework For Everyone?

kdawson posted more than 5 years ago | 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?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Choose them all under one. (5, Interesting)

jpyeron (456009) | more than 5 years ago | (#24094813)

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. (3, Interesting)

snl2587 (1177409) | more than 5 years ago | (#24095059)

I just have to ask: when does Eclipse cost $250? I assume that would be some sort of support plan, but I can't find it advertised.

Re:Choose them all under one. (1)

Matt Perry (793115) | more than 5 years ago | (#24095115)

Teraterm nice term, just don't like putty myself. (not needed outside of windows)

Speak for yourself. Not everyone likes the openssh client. Thankfully, there is a Linux version of Putty. Sadly, there's not a linux version of SecureCRT.

Re:Choose them all under one. (5, Insightful)

Anonymous Coward | more than 5 years ago | (#24095137)

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.

Depends (2, Interesting)

Anonymous Coward | more than 5 years ago | (#24094841)

It is OK if the tools are equivalent. Sort of like only using metric tools on your car. It is wrong if you can't use the best tool for the job and there are no reasonable alternatives (sort of like having a wrench when you need a screwdriver).

This type of micro-management usually fails because herding programmers is like herding cats. Programmers work best when they can creatively solve problems. They work worst when they are forced into a suit-mentality.

App Size? (0)

iamhigh (1252742) | more than 5 years ago | (#24094863)

I think it depends on the size of the app. Small and maybe mid-sized businesse apps would be able to get away with such a requirement, as their apps will probably not be pushing the limits of modern computers (and hardware upgrades are cheaper than software optimization). Enterprise apps should probably be done with the best tools available.

Re:App Size? (2, Insightful)

liquidpele (663430) | more than 5 years ago | (#24095045)

I see it not so much as the size of the apps, but as the type of work place it is. If it's high turnover consulting stuff, I'd say this will make things easier for the business overall but will limit the new experience their employees get on the job. If it's a company that does any real development or research, it's a horrible idea.


Anonymous Coward | more than 5 years ago | (#24094875)

Someone already tried that whole "One tool to rule them all..." bit. (Just remember, the last guy died)

You. Lose.

Answers to your 3 questions (4, Insightful)

winkydink (650484) | more than 5 years ago | (#24094879)

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.

Re:Answers to your 3 questions (0)

Anonymous Coward | more than 5 years ago | (#24094967)

> 3. ... A lot depends on how well the team is managed.

Good point.

We'd go with: http://extremeprogramming.org/ [extremeprogramming.org] (or the like)

no (0)

Anonymous Coward | more than 5 years ago | (#24094885)

If management insists on standardizing on one language it will likely be something like Java, C#, or Python. These languages are jack of all trades, master of none.

Make sure it's not a half-assed standardization (1)

locokamil (850008) | more than 5 years ago | (#24094903)

Well, as long as your approved toolkit contains a sufficient variety of tools, there shouldn't be any problems. Make sure you aren't writing file crunching applications in C... there should be a quick and dirty language (perl? python?) available for analysis/protyping/instrumentation.

Oh yeah, everyone should use the same compiler and/or interpreter. There is nothing more annoying than attempting to reuse code that has been written for the .NET 2.0 framework when you are limited to the 1.0 environment.

Standardize the RIGHT tools (4, Insightful)

AKAImBatman (238306) | more than 5 years ago | (#24094907)

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 (4, Interesting)

CodeBuster (516420) | more than 5 years ago | (#24095111)

Subversion + Ant + CruiseControl = source control with fully automated builds and reporting and it's free (as in beer).

Re:Standardize the RIGHT tools (5, Informative)

Fred Foobar (756957) | more than 5 years ago | (#24095321)

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.

Re:Standardize the RIGHT tools (1)

bishiraver (707931) | more than 5 years ago | (#24095635)

Not to mention it can interact with unit testing frameworks for java, c#, javascript, etc. Jawsome.

Re:Standardize the RIGHT tools (3, Insightful)

visualight (468005) | more than 5 years ago | (#24095119)

Now that's logical, exactly the right answer. They'll never buy it though, unless you can write book about what you just said, and invent a catchy new buzzword to describe the concept. Something like Dev 2.0..., or better maybe an acronym, like PEAT

Re:Standardize the RIGHT tools (3, Funny)

forkazoo (138186) | more than 5 years ago | (#24095539)

Developer Centric Individualized Standardisation.

Look forward to my upcoming book on the subject:
Development 2.0 : Practical Perfection With The "DeCISt" Paradigm in the Enterprise.

Seriously, a year or so ago, a friend of mine and I were just about ready to write a book about the benefits of procedural programming in C using a simple text editor, and then just buzzword the shit out of it and hype it up like Xtreme Programming and such, and pretend it was a new revelation. For the life of me, I can't remember what we were going to call it. Something like the Post Object Paradigm, or Modern Objectless Development, or some such shit. We would have made millions if we weren't lazy asses.

Re:Standardize the RIGHT tools (1)

daemonburrito (1026186) | more than 5 years ago | (#24095639)

I can't tell if you're making fun of Extreme Programming proper, the way it is defined here: Fowler tract [martinfowler.com].

It strikes me as pretty cool... Just an unfortunate name.

Re:Standardize the RIGHT tools (0)

Anonymous Coward | more than 5 years ago | (#24095567)

They'll never buy it though, unless you can write book about what you just said, and invent a catchy new buzzword to describe the concept.

I think you're on to something there. The book's not a problem, how many PHB's actually read the books they buy on software development? I'll write the book by just writing 'I am a fish' 40,000 times and getting it published. Next we need an acronym, how does this sound?

Ignorance or

If we can just make those PHB's think when they're overruling their technical staff, 'Hold on, maybe it's me who's being an arrogant git. Maybe I should listen to these experts and we should standardise on a toolchain, not just an IDE/language.' Maybe we can change their minds, or maybe the acronym for PHBs should just be: STFU?

Re:Standardize the RIGHT tools (5, Insightful)

mysidia (191772) | more than 5 years ago | (#24095215)

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.

Re:Standardize the RIGHT tools (2, Insightful)

dlanod (979538) | more than 5 years ago | (#24095313)

It depends on the scale of "company-wide". This would be absurdly stupid for a large multinational, or even large national, because they inevitably cover such a wide range of areas where software development may take part. Think Sony - PS3, movie DVDs, games, interactive CDs, all being written with the same set of tools. They would be gimping themselves from the start.

However, in a smaller company of a few teams within a single location and working on similar projects (e.g. all application development), this can greatly aid general understanding of code, code re-use, etc. So there are definite benefits in that situation.

The net answer would be the obvious "it depends". There aren't enough details on the circumstances in this case to make a decision. A lot of people will jump on it and deride the management for these dictates, but they can definitely make sense and provide benefits in some situations.

A gross misunderstanding of the process (5, Insightful)

Anonymous Coward | more than 5 years ago | (#24094925)

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.

Depends (1)

afidel (530433) | more than 5 years ago | (#24094927)

Are these all greenfield projects, or is there code maintenance of existing projects? If there are existing projects in various languages that need to be maintained then how does it really help to standardize new development since you're already maintaining the skillset around those other programs. Also what languages are any large third party apps written in, for instance your CRM, ERP, etc platforms. Sure most now support web services, but are you on a version that does? Oh, and does a significant enough percentage of your staff have mastery over one language so that you won't be wasting resources while everyone ramps up on the new standard?

restrictive (1)

icepick72 (834363) | more than 5 years ago | (#24094931)

It seems a bit restrictive nowadays. For example, you could use the same framework and features in every project but use a different syntax, like the .NET Framework can be programmed through C#, VB.NET. J# and 50-odd other languages meaning people can actually leverage their existing skill set instead of learning the "one and only" skill set.

Start sending out resume... (5, Insightful)

Fallen Kell (165468) | more than 5 years ago | (#24094951)

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... (5, Insightful)

alexmin (938677) | more than 5 years ago | (#24095087)

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

Re:Start sending out resume... (4, Funny)

CodeBuster (516420) | more than 5 years ago | (#24095171)

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?

Re:Start sending out resume... (1)

macslas'hole (1173441) | more than 5 years ago | (#24095263)

You can run away or you might do what I do. I so hate not having access to my tool set that I bring my own hardware in. I use an external HD that stays at work. It has my virtual machines on it setup just like how they would have setup my workstation. I come in, plug in my laptop, fire up Parallels, and get to work. All my unix and mac goodness is just a cmd-tab away.
If you can afford it and they let you do it, its really the best way to go. They setup the VM, on their HD, which never leaves the premises. You have instant access to your tools, on your hardware, that you control and are responsible for.
If they won't do that for you, then fsck them.

Re:Start sending out resume... (1)

Jack9 (11421) | more than 5 years ago | (#24095555)

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.

The day that management treats all programmers as interchangeable is the day you get guaranteed on-the-job training AND get paid for it. Are you nuts? At my work, they don't care what your specialty is, they care if you are a problem solver, smart, dedicated, and enjoy programming. This leads to a GREAT work environment. I dont think you understand what the base assumption is. There is NO shop that operates on purely 1 language (how do your cron jobs work if you decided to only use javascript? do you have to write your own os too?), so this is an obvious oversimplification. However, if the choice in a development language for a give project is always assumed, how is that anything but a time saver and money saver (in terms of searching for talent)?

Re:Start sending out resume... (0)

Anonymous Coward | more than 5 years ago | (#24095613)

Exactly! Non interchangeable programmers get fired when the old tech goes out and the new tech comes in.

And more often than not this shit is more political than technical. Programmers foolishly get caught up in the vendor-wars, but nobody's buying them 3 martini lunches.

If your boss wants you to switch from language A to language B, you should rejoice because it's one more thing on your resume.

Depends (2, Interesting)

twatter (867120) | more than 5 years ago | (#24094953)

I'm not a very experienced developer. I've worked at two different companies so far, where I was lucky to learn from some people who were.

The way I'd see this is whether or not you have a one-size-fits-all framework that will be useful in many different situations. But you have levels. For example, you can do pretty mcuch everything with VB.Net or Java, from web apps to desktop clients. So at that level you should pick a good, mature, supported platform that fits your basic needs (Linux, Windows, whatever).

The next level would be the stuff you pile around the base language. That's where it gets interesting. Some people swear by one ORM library (Hibernate) and others prefer whatever they used at the last project. So if you dictate Hibernate and Struts, people who were used to something else might not like that.

But if you don't standardize, you'll find yourself trying to wrangle nine different stacks that might do the same. How much is that worth? It's a waste of time and treasure. My company currently runs MS SQL, Oracle, Sybase, Ingres and MySQL. Why? Probably because at some point someone said "screw Oracle, I'm doing this with Sybase because I like it" and the rest is history. Extricating yourself from that can take years.

If the person making the decision to standardize on LibraryX is knowledgeable enough to make that call and he is making it based on the requirements of the company and the skill levels of the developers (current and future), then the standardization will work. The developers who work there will have to adapt and learn if necessary. Less-experienced developers (like me!) should not dictate what the company uses to ship applications just because they like a given library or toolset, because we choose what we *like* or what is cool rather than what is sustainable.

Anyway, good luck. I've seen how hard all that can be, especially at large firms.

Re:Depends (5, Interesting)

twatter (867120) | more than 5 years ago | (#24095063)

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.

Re:Depends (1, Insightful)

SerpentMage (13390) | more than 5 years ago | (#24095335)

The tech lead is an S&M friend! Give me a freaken break!

I use VS and Reshaper and am extremely productive. If I was using Java I would use Eclipse which is the same as VS and Reshaper combination.

The need to show "how good you are" with VIM is extremely lame!

Having developed for several decades I actually see the point of the standardization. That way you will not have one developer come in with their "latest and greatest" language that HAS to be used since everything else is so lame!

And if people don't like it they can leave...

Of course this goes on the assumption that dev had some input on the toolset, which is the case with half decent companies.

Re:Depends (1)

setagllib (753300) | more than 5 years ago | (#24095493)

I agree, even though I am very handy with vim, I wouldn't use it for a large project in, say, Java when I could use Eclipse instead. Eclipse has much much more advanced features and it really "gets" how Java projects are developed. I still write build and distribution gantries even for Eclipse projects, just to maximise automation and control for the products themselves. And sure, I'll write those gantries with vim, just like most short scripts.

Re:Depends (2, Informative)

Forbman (794277) | more than 5 years ago | (#24095643)

The need to show "how good you are" with VIM is extremely lame!

Well, you're thinking that the VIM guy really gives a tit what everyone else thinks. If he still codes 2x-20x what all the IDE people use, and he's happy, and his code works, he's not going anywhere soon.

I've worked with more than a few crack developers who can hunt-and-peck faster than I can touch type, which isn't slow... Oh, they happened to know as much of the internals of the business as the business people did...

Re:Depends (2, Insightful)

Forbman (794277) | more than 5 years ago | (#24095609)

Your company probably has all those RDBMS because somewhere along the line they bought an accounting package, say, that runs on Sybase. No, let's get real, Oracle Financials. HR somewhere got onto a package like Lawson or JD Edwards, because Oracle HR was too bloody expensive and the moneybags did not want to pay any more for Oracle DBAs than they have to. So it's Lawson or JDE on Sybase or SQL Server. And then maybe there was some budgeting, forecasting or other Enterprise-y application (say, data warehousing/datamart, business "intelligence", etc.), and because of the extortion being paid to keep various beta-level versions of Oracle Financials, along with all the in-house customization done on top of those, even though your company might have an enterprise-ish license, no one will give any authorization to do development against Oracle, and to a lesser extent, Sybase/SQL Server.

MySQL would indicate that there is a fondness for this Fine System for web application internet/intranet development, too. Plus, the licensing is nice, and the hardware costs are...well...they're commoditized, so it's easier for someone to say, "Hey, I need a database for this spec", and someone says, "OK, I'll build you a server on this fine '486 box to run it", rather than figuring out whether the SunFire box with the Oracle database on it can handle some more ad hoc querying for reporting and relatively light I/O.

Hey, I wonder if you have an AS/400 box or two running DB/2-based apps somewhere?

Don't worry about it. Most companies are a mish-mash of one Really Important Database system (usually whatever runs accounting and AP/AR), and a bunch of lesser tiers of RDBMS and servers, down to and including MS Access-based key applications...

Re:Depends (1)

IntlHarvester (11985) | more than 5 years ago | (#24095679)

A lot of times it's political or budgetary too.

"Man those Oracle DBAs are assholes! Just install MS-SQL over there, so we can get started."

Of course in the long run, the MS-SQL server is going to end up parked right next to the Oracle one with the same DBA team looking over it.

Type of Company? (2, Interesting)

RobBebop (947356) | more than 5 years ago | (#24094959)

In my line of work, the industry has been migrating from Cobol and Fortran to C/C++ in recent years. I have seen small bits of Java on tertiary projects. I have seen vastly different development toolchains.

My 2 cents? Standardize intelligently. Let experimental groups explore whatever they want, but reign them in when it is time to make evaluations.

One area that I love seeing standardization is in the tool for managing the software repository where you commit your periodic code changes. There are also benefits for standardizing on compilers and code libraries that you use.

One area that I hate to see standardization is in text editors. Let people pick whatever fancy or simple typing program suites their needs best.

Obviously, this post is not geared towards whiz-bang web developers who actually need to push the envelope a little bit to stay ahead of the latest trends.... but there is something to be said from the benefits of specialization and so I generally agree that *most* areas of company code development should be locked down and projects at the company that are not in compliance should have good reasons.

Increased productivity at a price (1)

cornholed (1312635) | more than 5 years ago | (#24094961)

Common development practices result in increased productivity and easier training for employees. The result is decreased flexibility (especially when new projects are evaluatedand) and long-term success. If management thinks they have a great thing going, good for them, I hope they don't run it into the ground, cuz they could kill any long-term momentum they have going.

It depends on how varried your projects are (5, Insightful)

MarkusQ (450076) | more than 5 years ago | (#24094963)

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.


Re:It depends on how varried your projects are (1)

MachievelianEngineer (933249) | more than 5 years ago | (#24095199)

"If you need to develop everything from hard real time embedded apps to web 2.7 social networking goo, you're screwed."

If you are trying to develop everything from hard real time embedded apps to web 2.7 social networking goo, you're definately screwed.

Too many "best" tools == lots of compat layers (1)

alexmin (938677) | more than 5 years ago | (#24094971)

After some number of features implemented most time is spent on maintaining those compatibility layers and not implementing core logic. Code monkeys breed, creative people become bored and leave.

What is your management getting paid to do? (0)

Anonymous Coward | more than 5 years ago | (#24094985)

Personally, I think your company is doomed, long term at the least. More nimble competitors will end up eating your lunch, while you end up saying "me too!". I've seen this before, alas. Monocultures are always brittle, and too frail if hit in the right direction.

There are two schools of thought as far as management goes. The first is that managers are all knowing, and send down orders from "on high". That the minions must faithfully implement.

The second school is that managers help and support their engineers on the frontlines. They provide overall, general goals and guidelines, and let the engineers do what they're being paid to do. Part of that is making the right decisions as well as implementing them.

The best managers look ahead at what their engineers will be needing in the future, and make certain that they have that when they need it.

It sounds like your "upper" management is of the first school, and don't realize that software development isn't a factory.

Good luck recruiting top engineers to work for you. Something tells me you'll be facing an losing battle there, as it sounds like you're doing your best to drive them straight to your competitors.

Re:What is your management getting paid to do? (1)

SerpentMage (13390) | more than 5 years ago | (#24095369)

Really? The company is doomed? Gee go ahead and tell Google that please! Or how about Apple...

For example if I were a Google employee could I use .NET? Ahhhh run to the hills...

Or how about if I were an Apple employee could I use Java? Ahhhh run to the hills...

These companies are successful because they have specialized in a toolset...

Re:What is your management getting paid to do? (0)

Anonymous Coward | more than 5 years ago | (#24095633)

Bah! Google Docs (nee Writely) was written in .net initially. I assume it's been rewritten in python or whatever now. But it wasn't when they bought it.

The premise fails it... (0)

Anonymous Coward | more than 5 years ago | (#24094993)

Choose the right tool for the job.

Caveat: C# is not the right tool for any job.

Yes... just as long as it's x86 assembler (0)

Anonymous Coward | more than 5 years ago | (#24094997)

everyone knows programmers have become fat lazy pigs. It's time for a return to the old days of squeezing out the maximum performance and proper utilization of resources...

I think it's time for everyone to go back to assembler and stop being so lazy... I say x86 assembler since everyone (almost) is using PCs anyways, it's not much of a stretch

Theoretically.... (2, Funny)

Anonymous Coward | more than 5 years ago | (#24095011)

All major languages are isomorphic and equally powerful (see Church-Turing thesis), so it should be possible for any programmer to use any language he or she wants to when working on any project, no matter what the existing code base is in. Sadly, the current generation of developer tools does not support this, though there are some promising next-gen projects which may solve allow this. Google "language-oriented programming" for more info on this.

In the mean time, the best approach is different languages for different tasks. If management refuses to accept this, I suggest you recommend INTERCAL as the standard language. It's a mature language (>30 years old) with many features not found in any other language.

No way. (4, Insightful)

istartedi (132515) | more than 5 years ago | (#24095013)

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. (4, Insightful)

ComputerSlicer23 (516509) | more than 5 years ago | (#24095621)

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 my druthers, it's: git, g++, Eclipse, Autoconf, and Ant, plus Python if I need a scripting language. It's the job. I get paid for my ability to adapt and overcome, not my ability to know a single tool. In my experience, a month or two, especially if there are others already comfortable with the toolchain is all the longer it takes to get to 80-90% efficiency with a totally new toolchain. Then again, I'm very complete in my reading of the documentation. There was a point in the 2.96 series where I knew every compiler flag for gcc/g++ that wasn't architecture specific for non-x86 architectures. I know most of the 4.x series, but I haven't read the docs cover to cover for the 3.x or 4.x series as I migrated to using Java at work about the time gcc 3.0 came out. Now that I'm back to GCC, I'm sure I will.


Hire an architect (1)

Toddsa (1321497) | more than 5 years ago | (#24095023)

It really depends and unless you have a very good dev management you will need an architect to make those decisions.

Can be very bad (1)

mysidia (191772) | more than 5 years ago | (#24095027)

Sounds like a way of slowing development

It only makes sense if all programs the company develops are able to fit the same cookie-cutter and do it well.

You are in effect forced to choose a language and framework that is mediocre, but suitable for everything, rather than a language that is preferred for the current need.

Basically, it pretty much means you are probably forced to pick Java or C# and .Net. Since some apps are sure to need a higher-performing, compilable language.

It's just mismanagement of development given a 'feel-good' justification. Since the mediocrity of any choices that will be suitable for a wide variety of applications, means every program will need many more 'utility functions' and classes not provided by the standard API.

Every application will need its own set of complex APIs, that developers have to learn before they can start coding on that application.

Either that or you wind up with one hideously-large bloated "framework API" that all the programs use.

The fewer application-specific tools the framework and language provide, the more of those tools will be specific to the application and have to be developed by hand.

(And then learned by developers before they can start coding on that project without breaking things)

The best language for one product may be a terrible choice for the next product.

A certain PHP framework may work extremely well for a certain type of web application -- and allow it to be developed in a few months, instead of a year.

Of course, cookie cutter frameworks only work well for applications that fit the mold.

One application may take 2 months in framework X to write, whereas other different applications may take a year to have written, just because of the framework.

Also, while PHP may provide acceptable performance for a web application, it is not acceptable for a desktop application.

Scripting languages are unacceptable for certain types of high-performance applications.

Compiled languages like C, C#, or Java are extreme overkill for a majority of web applications.

But using a common framework leaves no choice, and there will be much suffering.

There will be even more suffering if you can't write Makefiles or Ant build.xml files, and instead have to write your build procedures in java, because "java is the standardized language we're using"

It's dumb. (5, Insightful)

Maxo-Texas (864189) | more than 5 years ago | (#24095061)

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:It's dumb. (2, Interesting)

mcrbids (148650) | more than 5 years ago | (#24095449)

I'm going to disagree with you to a point. Having a standardized application framework makes a ton of sense when used for a for a specific class of product, and once chosen, should NEVER be deviated from. Having a "default" set of tools for an organization also makes sense, so long as the process for allowing deviations is reasonable. (EG: peer review by other techies, etc)

There is a *lot* of value in having a standardized framework for application development - working with one, it's a breeze to reassign programming resources as needed when circumstances change. Our application framework is somewhat "heavy", and we stress consistent code quality and layout, which means there's a longer learning curve up front, but once "up to speed", it's very easy to read each other's work. So easy, that it's usually damn near impossible to tell who wrote what without looking at the update history.

There is a *tremendous* value in this.

Re:It's dumb. (0, Flamebait)

fishbowl (7759) | more than 5 years ago | (#24095611)

>27 years experience and I've heard this idea before. It is dumb.

And you are (hopefully) not one of those people who refers to "upper management" as "them."
At the very least, you are (hopefully) willing and able to say "it's dumb" in the language
that "upper management" understands, and they (hopefully), understand the reason they pay you
is for the expertise to know when and how to say "it's dumb."

Re:It's dumb. (1)

forkazoo (138186) | more than 5 years ago | (#24095645)

Indeed, I can't help but think this is like a preview ad for an upcoming story on thedailywtf.com, where it all ends with some developer being forced to port an Occam runtime to his blackberry before he is allowed to rewrite "fortune" in Occam, so his boss can have his blackberry tell him pithy sayings every day, because the whole corporation decided the standardize on a platform that somebody's cousin's uncle's brother's hairdresser said was really up and coming. (And, they offer consulting services for...)

That said, it really depends on the situation. If absolutely everything is done in a new language, for no good reason other than developer whim of the day, and there really are a great many different groups working on different projects, then "soft standards" could be extremely beneficial.

If your company can dramatically narrow down it's list of preferred languages to C, C++, Perl, Python, Java, PHP, and Ruby, and if you have a good reason to use something else, pitch it to your manager first, and he'll probably be fine with it, then maybe it really is time to think about some standards. (Even if the Mac port will still involve some Objective C...)

More than just technology to consider (1)

Hairy1 (180056) | more than 5 years ago | (#24095075)

The point is that there is a cost to having a multiplicity of development environments. It makes it very difficult to move developers to other projects, and thus tends to increase headcount. Uncontrolled use of technology means that developers can implement systems with little oversight from other developers, as other developers do not have the skills to do proper review.

I am not saying that we should decide to use only one language, but a small subset of languages and skills seems to be able to get most jobs done. Supporting languages and tools needs to consider more than just technical considerations. What is the availability of skills in the job market? What kind of vendor and community support is there? What kind of productivity can be expected? Will the technology be supported in future, or will we be left with a white elephant?

Part of best tool for job is one people know (0)

Anonymous Coward | more than 5 years ago | (#24095079)

Part of the best tool for the job is one know by other people at your organization. If you get hit by a bus, somebody needs to take over your work. If the first thing they need to do is learn a new tool, it slows down the ability of your replacement to do the job. Furthermore, you will have a lot harder time discussing problems if you are the only person who knows the tools and language.

That being said, having a variety of tools does have its benefits. The big one is learning good ideas from one and applying it to others. Some tools do some jobs better then others (manage a large amount of data in flat files with C vs SQL DB).

These need to be balanced. Developers should not just bring in the latest tool they heard about into a major development. New languages and tools should be evaluated and tested on side projects, then if they bring sufficient benefit, incorporated where appropriate.

At my company, I watched (and fought against) a developer who brought a new tool in on his whim. He made incredible claims of the benefits while ignoring that nobody in the company knew much about the tool, including him. What he thought he needed and what he actually needed were two very different things. The interaction of the software he developed with the rest of the system caused massive problems. Unfortunately he was allowed to do all his development in isolation, prior to the rest of the system being in a state that could interact with his part. He declared his success, finished the project, and left the rest of us with the mess. Nobody wants to support the software he wrote. None of the benefits have been seen. Management does not want to pay to re-develop the software. It is a bad situation.

Asking for trouble (1)

bgibby9 (614547) | more than 5 years ago | (#24095097)

A one size fits all approach is usually a business decision to save costs rather than apply the most appropriate tool for the job. Your management is going to find that they will be able to address each project but they'll have the same type of solution bent to fit the problem. Good luck with that!

Microsoft (2, Informative)

DraconPern (521756) | more than 5 years ago | (#24095109)

You should look at what the majority of the developers are using to make this decision. If you are a Microsoft shop, and cost is not a huge issue, the combination of VS 2008, .Net 2 or 3, and C# and VB.net will fill your need and just can't be beat in terms of getting large teams to work together. Plus, you can always add php via VS.PHP. Unfortunatly, if you are using php, or something else, your choices are going to be all over the place for IDE and framework.

Re:Microsoft (1)

EEPROMS (889169) | more than 5 years ago | (#24095339)

Yeah right and Microsoft's IDE's and API's are not all over the place, seriously do you sell Microsoft products ?

Better to choose a process than an environment (5, Insightful)

Jabbaloo (237287) | more than 5 years ago | (#24095125)

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.

depends on use (1)

ianare (1132971) | more than 5 years ago | (#24095131)

It can be a good thing if implemented properly. If you have several equivalent applications/IDEs/languages then trimming some out is very helpful.
For example no need to use perl, python, and php for a web app, just do everything in one. I've seen some setups where you have php rendering a page, perl doing some text parsing, python as a script glue *shudders* ... sure you exploit the best area of each but when debugging or maintenance comes around it's a horrible, disjointed mess of spaghetti. (In the above case I would do everything with a good php framework)
As far as IDEs, you may get little 'weirdnesses' like whitespace not aligning right, peculiarities with a SVN server, etc ... If you can find one that handles everything you need, go for it.

On the other hand, nothing sucks more than needing a particular tool and it not being available due to some stupid policy.
If you need a particular tool because no other is suited for that purpose, then use it.

Two (4, Interesting)

Tablizer (95088) | more than 5 years ago | (#24095169)

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.

Re:Two (0)

Anonymous Coward | more than 5 years ago | (#24095443)

Sorry, who got burned for being tied to Microsoft? Oh that's right, nobody. Because they are still around. They are still ubiquitous. And VB6 apps still work.

Re:Two (1)

Tablizer (95088) | more than 5 years ago | (#24095491)

And VB6 apps still work.

Yes, but it will be harder to find legacy developers who want to work on it or know it well.

Does everyone know the same languages? (4, Insightful)

gravyface (592485) | more than 5 years ago | (#24095189)

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.

The most important rule for upper management... (1)

mrroot (543673) | more than 5 years ago | (#24095201)

...is don't f--- it up.

Managers who come in and immediately institute sweeping changes are usually gone just as quickly was they arrived. What you are talking about is a strategy, not a mandate from a king on a throne. A strategy is something you move toward that guides your decisions. So maybe you standardize on two or three standards that can be used, and you get much of the benefit that way. But then again, if this is all about upper management's ego, then only one standard will do, of course.

And finally IT is not a plug and play commodity. If your IT department sucks, it is not because you need to standardize on a development environment. Maybe the company should "standardize" on hiring intelligent, qualified people and "standardize" the HR policies on paying them what they are worth.

Your workplace is about to go to hell (1)

kerashi (917149) | more than 5 years ago | (#24095205)

Your workplace is probably about to go to hell. So why not have some fun with it?

First off, update your resume. This is perhaps the most important step herein.

Next, recommend tools that are as bad for the job as possible while still not raising objections from your colleagues, or better yet, get them to go along with it.

Watch it fail utterly, quit in disgust, and watch as the company falls apart. ...


Addresses the big cost... (1)

higg (11739) | more than 5 years ago | (#24095211)

... Application Maintenance!

The biggest cost for any enterprise application is not the cost to develop it but the cost to maintain it. A company may spend a million dollars to develop an app, and then spend that much per year to keep it running, add enhancements, test OS/DBMS/AppServer/etc patches.

So by standardizing on a common set of tools and frameworks, the company can train all of its incoming staff on these tools and be able to deploy them where needed. It then allows the company to move staff among the various projects as needed without incurring additional costs to train on a new set of tools/frameworks/etc.

So, with this approach, you will never get the best tool to fit the job but you should end up with an adequate toolset.

Doom!!! (5, Insightful)

daviskw (32827) | more than 5 years ago | (#24095305)

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

A Business Case for Less Management (2, Interesting)

LifesABeach (234436) | more than 5 years ago | (#24095315)

Consider globalization as a solution. The single biggest overhead cost of any set of software projects is the Upper Management Staff. This group of people do not necessarily need to understand how the process is made, they only need to just find other ways of doing some process cheaper. By hiring staff that would cost roughly 30 cents on the dollar from some 'nth world government, the Investor/Owner can reap 70 cents in profit by reducing Upper Management. With the added benefits of not being slowed down by those not directly involved with the product. But the saleability issue is unignorable. For large groups of software projects, like the D.O.D. a different globalization solution would work more optimally. By using A.I.Alturnitives for the handling of such things as Logistics, the DOD can effectively reduce their cost savings by 90 cents on the dollar. The DOD does not really make anything. The vast majority of officers act as redundent support staff. One person could do the job of project effectiveness as an entire team of Middle Managers. As one Combat Engineer said, "Can Do." With the devaluation of the U.S.Dollar, one has to consider lifestyles of other cultures. The worst thing that could happen to the Owner/Investor is the giving back of profits to the Market. The only reliable solution for this is to convert to some other currency than the U.S.Dollar. I cannot help but think that Upper Management should be asking the question, "Should I stay with this firm? In this country?"

I have mixed feelings.. (4, Insightful)

suresk (816773) | more than 5 years ago | (#24095325)

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.

Its obvious (1)

LesFerg (452838) | more than 5 years ago | (#24095341)

Well of course you should all be on the same version of Visual Studio.

What... theres something else?

dev env (1)

jrussbach (1180355) | more than 5 years ago | (#24095359)

Management should strive to enforce a policy in which projects/code are checked out and built with a minimal set of compilation tools. i.e. javac, gcc, etc. libraries, dependencies included. "Development Environments" have clouded our view of simplicity. I do believe that a company should provide a standard base image so that developers can get up and running, but the real issue is eliminating the dependencies of IDE's and tools that people have grown to think that they need. I believe I should be able to check out a project and build it with a minimal amount of effort. Further development can take place with whatever tool I choose. Its about code independence not tool dependence. As for choosing the language... This is a hard fight unless you are an architect. Companies will usually dictate this.

GCC + Make + Emacs (5, Interesting)

martin-boundary (547041) | more than 5 years ago | (#24095371)

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:GCC + Make + Emacs (2, Interesting)

dosun88888 (265953) | more than 5 years ago | (#24095483)

In a sufficiently large company you'll have a good chunk of programmers (though I wouldn't call them that) that ave ever compiled anything without selecting "build" from the menu in Visual Studio. Try getting those guys up to speed on make and emacs.

You'll actually have to teach them something about code.

Re:GCC + Make + Emacs (1)

corsec67 (627446) | more than 5 years ago | (#24095573)

If a programmer has never interacted with make directly, how good of a programmer can they be?

Re:GCC + Make + Emacs (1)

techno-vampire (666512) | more than 5 years ago | (#24095663)

If you're doing development by edit/make, rather than inside an IDE package, it really doesn't matter what editor you use as long as you know how to use it. Let them use whatever editor makes them happy, even if they're the only one in the company using it as long as they save their work in ASCII. Making everybody use the same editor means that there's always going to be one nose out of joint, and that's just one more excuse for egos to get in the way of the work. Standardize on the things that make a difference, and let them use what they want where it doesn't.

I might be wrong (1, Insightful)

Anonymous Coward | more than 5 years ago | (#24095381)

I might be wrong (am sure some Slashdotter will enjoy correcting me in this), but the difficult part of moving between projects is not differences in language. It's differences in the mindset of the who wrote the existing code: the naming conventions they use, any nomenclature specific to the project, what classes are responsible for what functionality, etc. Learning all that malarkey is the difficult part.

Obviously extremes are bad, if your company is using tens of languages, you might want to start looking at ways that can be slimmed down. However I would argue that choosing a small group of languages that complement your core business is preferable to attempting to shoe-horn one language into doing every job.

Think of it as being like reading books by different authors: Java is Virginia Woolf [wikipedia.org], and PHP Charles Dickens [wikipedia.org], a book is like a chunk of code. Both authors have different writing styles, but anyone can still pick up a book written by either of them and understand the words written within.

What the PHB's in your company believe, is the difficult part of understanding the storyline in a book is getting to grips with an author's writing style. So everyone should standardise on one author to save time. The reality is, people will get to grips with a new language within a few pages, but won't understand the concepts of the whole until they've read most of it.

I know: most borked analogy ever. But hey, I'm bored of hearing about cars. :)

Re:I might be wrong (2, Interesting)

moexu (555075) | more than 5 years ago | (#24095649)

I was thinking something similar; the hardest part of moving between projects is picking up the domain knowledge rather than the technology. Standardizing languages/tools/IDEs/etc does very little to address this.

If it were my company I would be interested in finding out the real problem that the PHBs are trying to solve. Are there too many different toolsets in use or do they think that by standardizing they will make everyone into neat little interchangeable cogs?

I worked for a company owned by a bank. The bank had its own developers and their PHBs wanted to standardize on languages (C# in this case) so that our teams would be completely interchangeable. They had this pipe dream that if one of our team members was out for a couple of weeks that they could send up one of theirs to as a drop-in replacement, and vice versa. The problem with that is that our company was doing something completely different and a replacement wouldn't be able to learn the business processes quickly enough in such a short time to do anything useful. The PHBs acknowledged that this was an issue but refused to abandon the idea that someday, somehow, our teams would be completely interchangeable.

Standardize development tools? Really? (0)

Anonymous Coward | more than 5 years ago | (#24095397)

Man... if my company ever made me move out of VIM as my editor, just for the sake of standardizing tools used, I would show them just how insanely it impacts my time. Then I'd quit. Working for incompetent management is hell on earth.

What these uppers need to realize is just how valuable a talented developer is, and give them good reasons for staying (and cleaning up the garbage). It's not a f***n factory... not everybody can do the same job in the same way. Lower management can help them realize that. That's the only way you'll get the job done more efficiently.

Let the dominos fall (1)

Toll_Free (1295136) | more than 5 years ago | (#24095399)

I hated it, having to support it as one of the infrastructure engineer, but Domino pretty much did everything, in an OK manner.

Our main developer was the head corp attorney, who decided he hated law and started working as the IT dept in the company. He learned Domino out of necessity, as the new CIO brought it over from the financial / insurance arena.

I hired on about a year / year and a half into the migration from MS Mail / BS apps to Domino. I stayed for about 2 years. Everyone that did domino dev talked big shit about it, but they all agreed, at the end of the day, it pretty much did EVERYTHING the company needed, in an OK manner, and did more in a lukewarm way than anything else could come close to delivering (read this as, it will do almost anything, although it might not do some things the most efficiently).

I don't even know if it is still around, but I'd check into Domino / Notes / etc. I hated it, we all did, but it did work. We even started collaborating it with stuff that HAD to run on OS/2 (Timberline) and some stuff that had us running Win 3.11 on some workstations (post y2k).

YMMV, of course.


Another recent decision (0)

Anonymous Coward | more than 5 years ago | (#24095425)

Upper management also decided to removed everything but a #2 phillips bit from the maintenance departments toolbox citing the rising cost of supplying 4 different kinds of screw drivers.

On the left... (1)

Cur8or (1220818) | more than 5 years ago | (#24095467)

in blue and black trunks we have the MS fan boys with their fat manuals and their Vista-bruised ego's. On the right in the rainbow trunks we have the OSS junkies with their man pages and up to date Firefoxes. Let's get ready to rumble!!!!

You're F*d (0)

Anonymous Coward | more than 5 years ago | (#24095527)

And not because of the particular number of languages. It's the thinking behind it: that programmers are just commodities. The idea is that if we standardize on, say, Java - that we can just replace one Java programmer with another and there are thousands of those on Monster.com. This type of thinking betrays a deep misunderstanding of development and if your management doesn't get this now, someone will have a lot of educating to do. Either way, I'd rather have a route canal than work there.

Um, maybe... (1)

zizzo (86200) | more than 5 years ago | (#24095541)

If everyone at your company is doing similar enough thihgs this should work out OK. I doubt you will see any bump in productivity though.

However, languages are tools. Like carpenters, software developers should use the right tools for the right job. Forcing everyone that's building your house to use exactly the same kind of hammer for every task doesn't give any benefit and will result in worse, not better, construction.

Unlikely to succeed. (0)

Anonymous Coward | more than 5 years ago | (#24095557)

The idea of a homogeneous environment is attractive -- it is obvious why management would be interested in this. But it probably will not succeed, or if it does it will hurt your company.

It will be costly, as your company goes through the inevitable investigations, debates and infighting to try and choose a plan. Then come the struggle to port every product to the new environment; during which time you won't be adding features. But once you actually get everyone on the same platform, you are not done.

What if you acquire another company? Will you port that technology to your platform? That is likely to be even more difficult and expensive.

How will you upgrade your processes? No piece of the system can be replaced unless it is feasible for every part of the organization. I guarantee there will be some nasty old projects that will hold back everyone else. Every toolchain decision will have to go through the CIO. I hope they have a lot of extra time.

In sort, while your company is navel gazing, your competitors who aren't locked down will running ahead.

A foolish consistency is the hobgoblin of little minds.

Root cause (4, Insightful)

sohp (22984) | more than 5 years ago | (#24095579)

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.

Good Plan for Bankruptcy (2, Insightful)

skeptictank (841287) | more than 5 years ago | (#24095619)

If all your company does is make websites(or web 2.0, cloud computing or whatever the buzz word is this month) this might be fine. If the company makes a variety of applications for different purposes or targets, then this is a really bad ideal. The engineers attached to the project are the people who should be making the decisions about the tools and languages that are used to actually make working code. Management above the project level is to far removed from the actual work that will have to be done to be making that kind of decision.

Anatomy of a successful software project (1)

khaledh (718303) | more than 5 years ago | (#24095637)

In most enterprise applications you'll be using multiple languages whether you like it or not:

- A multi-purpose high level language for n-tier apps (data access, domain logic, presentation): Java, C#, Ruby, Python
- A database language: SQL
- Web interface (if it's web-based): JavaScript, DHTML, Flash
- Integration and Middleware: XML

As long as you're within one product boundary, one general purpose language is the way to go. Across products (from same vendor or from different vendors): different languages + well standardized protocols (XML or binary serialization) is the way to go. Mixing more than one general-purpose language in the same product is usually a bad idea IMO (unless the languages share a common framework; e.g. C# and VB.NET)

The thing that ties everything together, whether using one or more languages is the development process and tools:

- Source control (SubVersion) -> provides change tracking, branching, merging
- Automated build environment (Ant, NAnt) -> can build code, database, tests with the push of a button
- Continuous Integration (CruiseControl) -> detect and fix integration errors early
- Unit Testing (xUnit) -> ensures predictable behaviour in the face of code changes
- Bug tracking (Bugzilla) -> track defects, plan fixes
- Documentation (Wiki, DocBook, code comments) -> inform your peers of your public APIs (i.e. how they can use what you have written), and possible extension points (how you can use what they have written); inform stakeholders how the system works (concepts, architecture, business scenarios); inform your users how to use your system properly

A good project manager ties everything together and keeps everyone on schedule.

Coming up to speed on New Environment? (2, Insightful)

skeptictank (841287) | more than 5 years ago | (#24095653)

If this is a major factor when ramping-up a new engineer on a program, then your application domain is probably so easy that your jobs will be outsourced to Albania soon anyway.

Are the tools really the blocker??? (0)

Anonymous Coward | more than 5 years ago | (#24095675)

Does it mean that if all engineers in the World use Autodesk CAD for their jobs - it would be easier to put buildings architect as a part of space ship architectural team, then?

I mean - are the tools really critical here? Hardly, IMHO. The problem the team working on is the most critical thing. Tools are tools and are changing still, we have to accept this. Changing the tool (to some degree) is peanut compared to changing (business) problem You are working on.

Also, please send Your management copy of DeMarco's "Peopleware" copy... And hopefully the will finally know that developers ARE NOT INTERCHANGEABLE, whatever You will try to do.

Outlaw all religions except... (1)

betelgeuse68 (230611) | more than 5 years ago | (#24095687)

The church of flying spaghetti monster:


That and make everyone on earth speak Latin... I'm sure it will all work out somehow.


Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account