Slashdot Mirror
Does Company-Wide Language "Standardization" Work?
RMX asks: "In our company, we're currently going through the debate of standardizing on a computer language for our next set of products. The pro-standardization guys say that a single language (like Java) will save everyone time. The anti-standardization guys are advocating a mixed environment (of languages like Python, Ruby, and C#), and argue that the whole discussion is as silly as a manufacturing firm standardizing on screwdrivers for all their screw/nail/glue fastening needs. Have any of your companies standardized on a language? How well did it go?"
It's still the best tool for the job in some fields.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
"If this standardization is being driven by upper management, they are hoping to turn the developer positions into a cookie cutter role."
-- We agree!
"A single language makes each developer easily replacable."
-- Dream on! At Wells Fargo, they have a bunch of hackers that have no concept of design. If you think a similar language helps, I want some of what you're smokin'.
These kinds of things are usually dictated by a CIO who knows nothing. They are usually pushed by a vendor (either MS or Sun) and after a few dinners, a golf outing or two and maybe a nice watch the CIO makes the ruling that everybody is going to use the same language.
What's even worse is when the CIO dictates not only are they going to use the one language pushed by the vendor but that they will also use the vendor supplied toolchain, servers, and operating systems.
That's how "windows shops" are born. Anybody who thinks that all problems are solved by what one vendor sells is either a zealot or gullable.
evil is as evil does
Especially when you have languages like Jython available, standardizing on Java and Python makes sense.
A similar scenario where the Java programmers wanted to outlaw all other languages. In my biased opinion, they were afraid they would be out of jobs if anyone got around to comparing their productivity in Java with the productivity of the Perl group.
Two people coding Perl were able to finish a large project in roughly three months. The same amount of time the Java group said they would need to complete the job specification.
I'm not saying Java is useless. But you really have to wonder when people start suggesting you outlaw perfectly good tools ...what are they afraid of?
at the pharma company I work at. We were all java, C++, LISP, Smalltalkers before. It's been four years now, and it was a wise decision. It's a very adept glue language that has been easy to integrate with other systems, both at the source code and network level. YMMV, and I think perl or ruby both fill this niche well too. We just wanted to have a standard platform for new development, and have been pleasantly surprised that python has been a productive choice for legacy integration and utility tasks as well. We had a requirement recently to integrate with a Java system. I used jython and it took three days, with no curly braces to be seen. We get a lot done every day now, and it's quite motivating.
There are two issues here: using a single or mixed language approach for a particular application, and using a single languange (or not) across an entire organization for all projects.
I worked for a long time at a big national lab that was mostly a FORTRAN shop. They wanted to use FORTRAN for everything, and it was technically a bad choice for everything, but culturally it was the only solution that would fit without causing a jihad among the old timers. I much prefer C++ for these sorts of things (big complex simulations that must run fast), but had little success in converting the masses, even though it was always faster, more portable, much easier to maintain and handle complexity, and also you can actually hire good C++ programmers.
We were able to do some mixed language solutions (C++, FORTRAN, C, perl, etc.) and they were a nightmare to maintain. in hindsight, I think it would be better to keep the apps all in one language rather than mixing. The biggest problem here is portability. These applications have incredibly long lifecycles, and the platforms change severals times underneath you, which seems to affect the inter-language interfaces the most.
Anyway, it depends a lot on the type of application, lifecycle, target platform(s), etc. but I think in general it is best to pick a single language if at all possible for a particular application that is the best single tool for the job. But, if a different application would be better suited for a different language, go with the different language. Mandating a single language policy across an organization for all projects is counterproductive: use the right tool for the job.
I've never tried standardizing on a language after the fact, so I don't know how that would work. But I am a firm believer that a common language for the development team is a good thing. Much like a common spoken language for the team is a good thing. It encourages code reuse, sharing, and general system understanding. On the occasions that something in our system is written in another language (we had a few C modules from contractors and third parties), it usually ends up being a mystery system and we accept it with it's behavioral limitations or we end up rewriting it in our own language (which happens to be Perl) so we can tweak it as needed.
Of course we actually do use several languages: perl, SQL, DHTML. But each one covers a very specific, non-overlapping domain. I've tried to stay away from having a second language cover the same need in a different way. It's hard enough to keep everything understood and shared as is.
Cheers.
I work for an internet pioneer company that has survived the .com crisis and continues to thrive. However 3 things are golden. Bash, Perl, mason. It is not the quantity of tools you have, but the right swiss army knife. Granted there are times you need a surgical tool for the job. Just keep the pool of tools small and versatile and all will be well.
I've had mixed results with standardizing on a language. All too often it's done purely for the sake of standardizing, with no thought to anything else. Programming languages are tools, and ones being used by a team not just one person. You want to minimize the number of variations in your tools so people don't have to worry about needless vagaries from one tool to another. At the same time, you don't want to standardize so far that you eliminate entire kinds of tools and end up doing the equivalent of trying to use a rock as a hammer because your shop's standardized on screwdrivers and screws for holding things together and so doesn't have hammers (the programming equivalent would be trying to do simple scripting jobs, that'd be 5 lines in Perl or bash, in C++ because that's the language your shop standardized on).
The only times I've seen standardizing languages work is when the first step was to not standardize. The first step in a successful standardization effort will be to ignore languages and instead take stock of what kinds of programs you need to write. Include all those little one-off jobs that you have to do several of every week, eg. the little hack to extract the error messages you're interested in from the logfile. Then, for each kind of program, look at the languages suited to writing that kind of program and see what one your developers are most comfortable with and, just as importantly, what your existing code is written in. An inferior langauge that all your developers know well is superior to a superior language that they're not familiar with, and if you've a large body of code in one language then that language is better than a different language. If several kinds of programs can be served sufficiently well by one language, well and good. If not, well and good too. The goal is to simplify getting the job done, not hamstring yourself with rules not related to getting the job done.
In the Unix world, normally I expect at least 4 standard languages. You'll have shell script (typically sh because so many other tools expect it, but csh is possible), make (because every development environment typically depends on make at some point), another scripting language (Perl, Python, Ruby, etc.) and a "real" programming language (commonly C, C++ or Java, add VB and C# in a Windows environment, others are possible).
They aren't dogmatic about it and there are many more languages in heavy use at Google. Orkut is written in C#. Google also uses Javascript/Ajax extensively for many of their client-side sites. If you want a good illustration of how ridiculous it would be to insist on single language such as Java everywhere, imagine if all their sites (e.g. maps.google.com) had to be provided using Java applets.
This is what lead engineers, or architects (responsibilities and titles vary by team) are for.
There should be a chief, and he should listen to the opinions of the entire team. Then, using his expertise, wisdom and the input of the team, he/she should make the decision.
In fact, a good architect or lead should have a good instinct for this... it will be highly dependent upon the system architecture, team makeup, etc. If the pieces are easily seperable (say, a c# GUI app that communicates to a ruby-on-rails web service), and most developers on the team know both languages, maybe multiple languages work. On the other hand, if only one or two programmers know ruby (or c#), or you're talking about one app that uses both languages, the situation gets murkier.
I've served as a lead dev / manager for teams in both scenarios. In the past, I developed a large system based on Delphi combined with C++ (several applications), and recently a whole system with C# (again, multiple applications and components). I can say that both are doable, but each was approach was tailored to the requirements of the system.
That's ... one way of looking at it. A wrong way, but a way nonetheless. Did you ever consider that each extra language costs money (whether the environments are free or not) to implement? Why should I have four languages that all produce web applications when any one of those four can perform the same tasks as the other three? What possible reason is there to re-invent the wheel three times?
I'm an IT Manager, pushing standardisation. No dinner, no golf (that'd ensure I didn't use that vendor's language), no watch. As to whether I know anything, I guess you'll have to track down the people in my area. The development manager seems to think we're on the right track though.
Alister
several companies I've been at have standardized on a single language for "the customer product" (it's always been C or C++) while for strictly internal tools it has always been a free for all -- Mostly Perl but also Python, Expect, TCL and even bourne shell.
Using the "standard language" never seemed to be a problem for us.
Of course my experience is limited to enterprise computing and embedded software (no MS Windows shrink wrap).
A few years ago we have standardized on Java on the client workstations but it simply doesn't work. Whenever an application is converted to Java helpdesk tickets soar up in the sky. Not because of technical reasons, there are almost never any bugs involve. No mostly because users doesn't seem to be happy with Java applications since they don't feel what the users are used to. Even with trying to implement as much of the users complains as possible. Sure the complains slowly die down but not to the level as for none-Java applications.
We are now considering to replace Java with AJAX for the simpler DB oriented applications and C++ for the complex applications, hoping to halve the helpdesk tickets count in the long run. It seems C++ together with the wxWidgets framework produces produces enough good applications which users are happy with.
See http://wyoguide.sf.net/papers/Cross-platform.html
> Ada was developed by the DoD precisely because they wanted to have one programming language for the entire US department of defense. Naturally this was a massive undertaking. The programming language had to be all things to all people, and thus grew very, very large.
:)
That was a popular critique 20 years ago, but these days people tend to criticize it in the opposite direction (i.e. no standard class library).
> The problem with this large programming language is that it is so complex that most programmers can't know all of it, and they only use a part of it. That, in turn, becomes a problem whe two sequential developers on the same piece of code know different parts of the language, and the second developer can't read the first developer's code.
I don't think that's correct. I'll be the first to admit that I don't know every obscure feature, but then I don't use it professionally either.
> It also produces a few problems in trying to build a correct, compliant compiler
I have heard that that was true when the spec was first published a generation ago, but any such problems have long since been solved.
> So the point here is that "standardizing on one language" has been tried before, and it was a huge flop.
But a political flop rather than a technical flop. By the time the DoD was ready to start using it everyone wanted to program in C++, and the administrators were giving out waivers like Halloween candy.
Also (as often seen by people's ill-informed comments about it on Slashdot (no, I'm not referring to your post)), Ada has an unjustified bad reputation based on ignorance, such as the oft-encountered claim that the first Arianne 5 rocket crashed due to a problem with Ada, and oft-encountered quotes from Hoare (saw it as a Slashdot cookie earlier today, as a matter of fact) that was actually a critique of an early draft of the language. Much of Hoare's critique was addressed in the final project, and of course we've had the '95 spec since then. (And an 0? update coming out RSN.)
People who actually use it tend to have a high opinion of it. I use it by choice for my hobby projects.
Also, the switch from complaints about it being "too big" a generation ago to being "too little" now show just how fickle out notions of what a language 'ought' to be like actually are.
Sheesh, evil *and* a jerk. -- Jade
Agreed. If an underling wrote bad Java code, I would reject the code review. If they wrote bad Ruby code, I would reject the code review. There is really no difference what language they wrote, if they can demonstrate a reason for using a different one and there are no strings attached (e.g. as there are for anything attached to .NET) then no problem.
Karma: It's all a bunch of tree-huggin' hippy crap!
I settled about a year ago on two things: 1. Use the right tool for the right job. Web applications, which perform most of the processing on a remote server, are very different than GUI apps that run on a user's desktop. It's stupid to think that one language is going to provide everything you need in every case. GUI apps need strong typing to run quickly and keep the end users happy - Web apps need rapid design to keep the VPs happy. End users love GUI apps and hate crashes; VPs love Web apps and don't care if if an app crashed from time to time as long as it mostly works and gets done NOW. Pick whatever language is appropriate for the task. 2. Learn from Java. Java has its warts, but from a structural standpoint it's probably the most solid language I've ever worked with. These days I mostly work with apps that target mod_perl, but my code - and the code of anyone who works with me - is required to adhere strictly to Java's naming convention, must follow a pure OO paradigm, and do its best to act like a JavaBean, with "getters" and "setters" properly implemented and static and normal methods documented as such. By doing this, I've managed to make Java programmers actually like working with Perl... something long thought to be impossible :)
Beauty is just a light switch away.
My boss is confident enough in his staff and himself to be able to pickup and maintain whatever the developers decide to do their job in. Currently I have written C#,Java(JSP/Servlets,J2ME/MIDP, server applications, Blackberry J2ME stuff, Applications), C/C++, Tons of Shell scripts, XML, LaTex, HTML, XML running on Solaris,Windows,FreeBSD,various flavors of Linux. All of which ultimatley connect to either an Informix or Postgresql database of which the host apps are running on an old legacy SCO UNIX system. Whatever does the job best is our motto. Id hate for my boss to walk in and say convert everything to . It would be hell.
Oooh yes...this is where it's really going my friend...and it's gonna hurt so much...
In time you will realize what is really at stake...and it's not Java or not Java.
I saw this personally. I was working at a very large US telco, which had bought many smaller telcos in a short period of time, all using mainframes really. The old timers managed to make all work together nicely, cobol, fortran, c, whatever, it worked.
First, they "standardized" on Java, and one and a half seconds later, they "standardized" on India.
The problem with us programmers is that we don't think like managers. For IT managers, having outsourced all they could is a VERY GOOD thing and it's the hip thing these days. It's a promotion for them. Go to Amazon and check IT management books. They RECOMMEND it. We programmers just don't see it, it's only natural, we code, we are not managers. It is just like it was Java for programmers in the 90s, you had to try it. IT managers are not there to make sure you have a salary, they are there to make sure they have a salary.
And for India, the only way to get started in the game is to standardize on J2EE: not even Java, J2EE. Most of those programmers (personally seen it) can't override java.lang.Object.hashCode(), but they can deploy an EJB.
What was ludicrous about the situation is that being the company very large and rich, they could actually afford to create the outsourcing company themselves from scratch and "make it profitable". They went to India, found the people, interviewed them, prodded them into EJB programming. They used to show us "before" and "after" photos. (There used to be a field here, look at the data center now)
The code itself...oh my God. First thing I saw was a 15 THOUSAND line jsp page, it was average. The guys down in India where such beginners that the company had to buy a million-way mega server from Sun to keep the "portal" running for at least 24 hours straight, and most of what the "portal" was doing was screen-scraping the mainframes (I am not saying Indian programmers are not good, I am just saying that the good ones are already taken/gone to the US etc).
So, in my humble opinion, yes, you can standardize on a language, especially if you take your management's solution, Java, which is all things to all people, provided you use 10 people to make a 3 page website, use a Sun 100-way machine, and you get custom patches to Weblogic from BEA to your custom problems, since it's included in the multi-million support contract.
But as a US programmer (I am assuming you are) you will be made to eat so much manure, you will be sorry you had'nt left.
Just my two cents from personal experience.
The best tool for the job is not necessarilly the language the lead programmer likes best.
I've worked in the industry for 8 years, and seen the results of standardising on a single language (or platform) firsthand. It wasn't pretty.
Of course code reuse is all nice and furry, but it's hardly ever practiced.
Far more often you find out after several months writing something that another department has a project doing exactly the same thing (especially in multinationals, sometimes even in the same building, and yes it's happened to me twice).
What is needed is a middle ground between rigidly always using X, and chaos in which everyone uses what seems like a good idea at the time.
Sadly the larger the corporation is the harder it is to get the people making such decisions to leave any authority in the hands of the people below them who have to implement them, leading to dictates from up high which are to be treated like gospel.
For example in one company there was a policy decided at board level that EVERY project HAD to be implemented using all IBM technology on both hardware and software.
Web application HAD to be EJB (yes, they dictated EJB, not just Java) with lots of XML using DB/2 as a database and Websphere on AIX as an application server.
No discussion possible.
We went ahead and used JSP/Servlets on HP with Oracle instead, hiding the purchases behind massive smokescreens, and noone was any the wiser.
This was done after IBM themselves advised us against using EJB on Websphere.
We could get HP hardware and Oracle cheaply (fraction of the cost of IBM) and quickly (instead of waiting a good time for delivery), and it was in tests deemed more reliable and better performant.
Now AFAIK the entire serverfarm uses HP and Oracle, and I doubt the board knows about it...
You betcha. That's the situation at the company I'm working for, and we're attempting to rectify it. The problem is right now we have just about every language that's ever been used: COBOL, Fortran, C/C++, Delphi, PowerBuilder, VB, Java, VB/C#, Perl & Python. And those are the only ones I know about!
As a result we also want to standardize on a language - or at least a set of languages. The purist in me says you should use the right language for the right job. The practicalist in me says you should use a language that's easy to find developers with talent in that language and can handle any business application coming our way.
The fact we have a plethora of languages is indicative of a lack of management oversight. Developers can pretty much do whatever they want - as long as they meet their deadlines and functionality requirements. Some managers manage the technology more than others - but there's no overall consensus throughout the organization.
Our challenge now is we have a newly-formed group managing the development tools and languages and the developers are resistant to any changes in the status quo. Especially looming large is a potential showdown between Java and C#.
I don't mean to flame, but with all these religious wars going on in IT it's become apparent to me why so many companies have turned to outsourcing. How are other companies managing their technology without engaging in holy wars?
I know your list wasn't meant to be complete, but you missed one case that tends to get ignored a lot on slashdot. That's OK, the bulk of the people hanging out here are developers or have a development focus, so they tend to forget about the rest of the IT staff. ;)
Think of all the scripting that gets done by the network and system administrators to keep everything humming along. It's almost always unrealistic for that staff to fall into line behind a single corporate wide language that was chosen to support a completely different set of design requirements. Heck, in their case it's virtually impossible to pick a single language due to differences between platforms and availability of tools. For example, in most cases they're happy if they only have to worry about choosing between Perl, Python, shell scripts, and/or batch files on *nices and/or Windows. Then there's JCL or ?? for the big iron plus Ghu knows what for rarer platforms like Tandems.
None of the above takes into account the network admins who, in addition to worrying about the differences between (again, for example only) Cisco and Juniper, also have to have at least a basic understanding of whatever scripting language(s) their management consoles support.
Anyhow, I agree that the idea that all coding done by a company can be done in a single language is wrong for all the reasons that you enumerated, and I agree that a list of standard choices based upon requirements is very important. That single sheet of paper probably needs to grow to a sheet and a half or two sheets to cover all the possibilities, though.
Seems a better choice would be: Pick one from each group:
And then exceptions should occur for anyone who needs more advanced capabilities from their languages (Haskell, ML, the K language, Lisp, etc).